Eastron SDM230-LoRa - LoRaWAN issues

I’ve recently obtained a prototype Eastron SDM230-LoRa electricity meter. In their datasheet they specify that they are using ASCII as the payload of the LoRaWAN messages. And to make it worse they are adding the serial number, the size of the payload, and a crc into the payload - things that are already provided by the LoRaWAN protocol. Also the message format is a byte in the payload, but the correct way is to use the LoRaWAN port.

How would one convince a vendor like this to improve their protocol and not waste precious airtime on redundant data?

Datasheet:
https://1drv.ms/b/s!AtOrHr967RVTgp81hRni28yz32Jkxg?e=zWtTIV

Further description (contradictory) of payload format:
https://1drv.ms/w/s!AtOrHr967RVTgqBFlFqnczSq5m76nA?e=iHbePq

1 Like

Here is one attampt to explain things to them:

Hi <vendor>

I’ve been reading through your documentation on the LoRa protocol. I understand it well.

One thing that I am concerned about is the protocol you use. ASCII!! LoRaWAN’s guidelines clearly states that one should not waste space and use ascii, but rather compact binary protocols.
https://www.thethingsnetwork.org/docs/devices/bytes.html

For example a normal request to your meters look like this:
30 31 30 34 30 30 30 36 30 30 30 32 39 31 36 61 (16 bytes)

By doing it in pure binary, skipping the unnecessary conversion to ascii, one can make it:
01 04 00 06 00 02 91 CA (8 bytes)

Because the first byte is always 01, we can leave it out.
04 00 06 00 02 91 CA (7 bytes)

The Function Code can move to the LoRaWAN fport, as this is meant to describe the function:
FPORT 04: 00 06 00 02 91 CA (6 bytes)

Because the LoRaWAN payload already has a Message Integrity Check (MIC), and the uplinks have a CRC, we do not need to put a CRC into the command:
FPORT 04: 00 06 00 02 (4 bytes)

So we just decreased the downlink command from 16 bytes to 4 bytes, by using LoRaWAN properly.

On the uplink side we can do exactly the same and decrease the message from
(3 + N + 2) x 2 = 2N+12
TO
3+N

LoRaWAN uses the shared ISM band, and we all should do our best to decrease the airtime of our devices, to keep the ISM band as free as possible. I am also very concerned with using your meters in big residential buildings where we will have thousands of these meters. With the current system they will fill the ISM band completely. Using a proper binary protocol will clear it up a lot!

Would you please consider improving the protocol you use over LoRaWAN?

Best regards
JP Meijers

Unfortunately I got no response from them.

Is there perhaps a way one can report vendors like these to the LoRaWAN Alliance, and then the alliance forcing them to fix it otherwise their devices won’t be certified?

An example of a vendor that does things well is Axioma. They rely on the DevEUI to report which meter it is. The payload only has the absolute essential values, even encoded as diffs.

Given their location there may be a language barrier to overcome. Maybe try Google Translate?

Can you tell who’s radio they are using - they may be able to give them some feedback.

Otherwise we just need to litter the forum with “not a great device” type comments and keep sending them screen shots of Google searches - this forum is one of the highest ranked.

I don’t think they really care about airtime use in a shared ISM band.

Real-world consequences for themselves are that they might not be able to get the same update rate as their competitors (and still remain inside fair use policy), if they use such an inefficient scheme.
Telling them that you are considering to use a different product because of this (and telling anyone about this) would be a strong motivator.

Also a direct comparison against another product that is much more “smart” might convince them.

If it doesn’t bring any change, then a more public name-and-shame might work.
I think this can be a win-win situation if they allow you to give them tips on how to improve things.

1 Like

Analyzing the comms is showing more interesting things. After every uplink message TTN is trying to send a downlink to tell the meter to use RX1 of 5s. But apparently the meter is not accepting this setting and the network retries. So for every uplink a downlink is sent. The meter did join using OTAA.

Screenshot from 2021-03-04 13-04-14

Hey JP Meijers,

i just got the same meter. Please its possible to help a little bit with the settings? I am trying to add it to gateway but it can not forward the messages. What is the MAC, PHY version and frequency for this meter? Thanks!

1 Like

I couldn’t help myself and opened the devices. On the inside we can see an Acsip S76S

20210304_133339

The rest of the device is also interesting.

20210304_133357 20210304_133623 20210304_133659 20210304_133643 20210304_133628

1 Like

I believe I used the standard settings: Class C, LoRaWAN 1.0.2, Regional params 1.0.2B, OTAA join with the keys printed on the side of the device.

Maybe a quick line to them would be in order - they won’t want people thinking they were polluting the airwaves.

ACSIP makes the MCU/radio hybrid; a software issue in terms of an unwise payload is probably a mistake by the creators of the product, not the components within.

Finally with your manual and the help i made it work. I havent set the C CLASS. Thank you good angel :smiley:

do you have made the Decoder already? or you just trying to put it together?

I have a bunch of these meters on my desk as well, getting ready to set them up.

While the large packet they send is absolutely unnecessary for LoRaWAN and TTN, I do understand why they have taken this route. They have taken their regular Modbus devices and just added a LoRaWAN wrapper on top of it. So the long packet is in reality just a complete standard modbus packet. And its hard to argue with the appeal of having to maintain only one type of hardware versus two different types for modbus and lorawan. Purely from the maintainers point of view, of course.

Yes, and this is exactly the problem here. The vendor is using a wired medium’s protocol on a wireless medium. We need to be careful with the wireless medium, as it is a shared resource, unlike a cable between the sender and receiver.

Guys please try to explain that CRC in the payload is necessary to calculate and put it to the end of the message? if so please help how to calculate it. I tryed to put the message into CRC-16 calc but without success. Thanks!

No need to calc the crc, as LoRaWAN already has crc and a mic that guarantee that the message is valid.

so when i send downlink message i can leave it 00 00 last 2, right?

if you wish to send commands to the meter, then you will need to send them a valid modbus packet. That means you will need to calculate the CRC as well. Here is an online calculator for that: On-line CRC calculation and free library - Lammert Bies

I absolutely agree with you. It is not best practice by any means and should be avoided.

Doing it correctly wouldn’t really be two types of hardware (beyond the need for the LoRa radio) but rather two software versions or modes.

That said, if they wanted to keep the meter part running pure modbus, then the thing to do would be to add a software component capable of translating intention between LoRaWan “style” and modbus, rather than just shoving one through the other. That software could probobly live with either the meter firmware or the LoRaWan stack.

Typically the reason why this kind of thing doesn’t happen is that the organization in a position to do it sees no benefit in doing so - they take the cheap path and let their customers suffer consequences often not understood until well after the purchase / adoption decision.

That disconnect between ability to improve the situation and suffering the consequences of not doing so is why there’s a shocking amount of bad firmware out in the world.

1 Like