Migrating Eastron devices from V2 to V3

TTN V2 to V3 Upgrade Migrating Devices to V3
1

Hi, am attempting to migrate Eastron Electricity meters that were operational on the V2 cluster to the V3 cluster. On V3, OTAA is failing with the following:
image
The join requests are using the following channels in the EU868 frequency plan: 867.1, 867.3 and 867.5 whereas the default channels are 868.1, 868.3 and 868.5. Looking for some advice on how to address this as I do not want to loose all my connected meters once the V3 migration completes - Thanks

2

The meters seem to use non compliant software which does not fully reset to the default channel list which causes this issue. There is a way around this, go to the device settings, network layer (expand it), then expand the advanced settings and at the bottom of that list you can add ‘preset frequencies’.
Use that option to add all 5 additional channels used by TTN and you should be good to go.
Once the meter joined, check the uplink/downlink ratio. I’m using a few Holley meters and those do not properly handle the TTN MAC commands resulting in a downlink for each uplink. As there is no way to solve this for my existing meters I would love to know if your brand would be a properly working replacement.

1 Like
3

Thanks - join is working. Will perform some tests and let you know how it goes.

1 Like
4

Hi, apologies for the late response. I have successfully migrated the Eastron SDM230 meters to the V3 stack and have extended my integration to include the Class C functionality. Some observations:

  1. We order the devices configured to transmit total kWh to date every 30 minutes. The implementation by the manufacturer involves a rejoin every 2nd transmission, this results in a join every hour, quite an overhead. The data rate for joins and uplinks/downlinks is always SF10BW125. The spreading factor can be set via buttons on the meter but it is clumsy and time consuming. I have not found a method of modifying the frequency (30 minutes) of uploads or what data is uploaded.

  2. The formatting of the data packet is a simple wrapper around their existing MODBUS protocol and they have retained the CRC, this adds some unnecessary redundancy.

  3. I still have to get my head around the Class C fair usage implementation with respect to downlink messages and where/who is responsible for policing this.

1 Like
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.