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?
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.
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.
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!
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.
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!
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
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.
