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.
2 Likes
Leaving the way open for their competitors to offer a much more efficient and longer life product at same cost but much lower cost of ownership & life cycle costs, wiping the floor with them an next they know they don’t have a business!
Best approach is lots of people telling them they cocked up and then also flagging & naming & shaming and quoting across the internet as a good example of a bad implementation and how not to do it… if they are too thick to take hint and see error of their ways, and fix, then they deserve all the market does to them 
Start by mail bombing them (CxO team, Vp Marketing & Vp Engineering…anyone have a good contact list?) a link to this thread and the starting good implementation post from jp! 
1 Like
A post was merged into an existing topic: Help with Axioma W1 Water Meter and Tektelic Kona Macro Gateway
@jpmeijers Interesting topic, I needed to look into this one for a customer, reading datasheet says max distance 1.5km. Hoping it’s a mistake and they wanted to write 15km.
Reading in datasheet ASCII format afraid me for the second time in less than 5 minutes. So sharing your experience is great 
Neither number is meaningful; range is completely dependent on conditions
Thank you for your contribution, I have SDM230-LORA that came to me without programming, you can pass some documentation on how to make it report and the Downlink to obtain Step 2.
2 Likes
Good evening, I’m trying to integrate a SDM230-LoRa device to TTN.
It would wonderful if we can write down a sort of “wiki” on how to integrate the device to receive information from it.
Optimization of the message is not a something we can deal with.
Why don’t we cooperate to fill this google doc, like a wiki?
Thanks in advance
Yes, yes it would be wonderful, but given the nature of the device it’s not something we really would recommend so I think you are going to struggle to find people to “cooperate to fill” the rather empty looking Google Doc. It would help if you’d made some passing attempt to put something in it to start with as at present it looks like you want someone to do the work for you.
1 Like
Good afternoon,
it is true it’s quite a “blank” file.
I must admit I’m quite a total newbie with respect to LoRa.
I’m dealing with a Dragino gateway (which I managed to configure correctly) and I configured the device on TTN.
Now I think I’m in the same trouble as the user buscasolutions and many others that passed through this forum before me.
There is absolutely no “previous experience” collected about this device online. I would be glad to contribute to the document as soon as the college of mine which used to deal with LoRa before would come back from holiday. I was just trying to avoid scattering knowledges around.
Yes. It’s because this device is not a friendly LoRa resident, and therefore we do not want to advertise how to use it.
Your best option is to contact the manufacturer and ask them to fix the obvious issues this device has, and then provide you with documentation.
Uhm, I see.
So, just a question: is there any other energy meter for mono and tri-phase electricity consumption more compliant with LoRa?
Because I could find none 'till now.
1 Like
I keep seeing you refer to ‘LoRa’, and you mention a Dragino GW…just to be sure you mean LoRaWAN right? Your GW is a full LoRaWAN GW (Dragino LPS8, LG308, etc. not a Dragino SCPF/DCPF LoRa only device?) and you have device operating in LoRaWAN mode, right? Not LoRa only… LOng/poor messages not withstanding , as an Acsip based device atleast the meter can be/should be set up as LoRaWAN vs LoRa propretary.
Yes, sorry, my mistake. Dragino LG308, configured as seen in picture.
Great 
495 / 5000
Resultados de traducción
Hello fmanghi, delighted to contribute everything I can, from what I have been able to see, is that the team is a virgin so you have to configure first that you report and second that you want me to report. The manual where you can get the LORA information comes in SDM630 LORA. I need to create the command line to get: Voltage stacked power. If someone knows how to do what I contribute, Then you have to make it report every 1 min with the information that I have collected, I have not achieved it.Eastron_SDM630MCT-LoRaWAN_protocol_V1.0-combined_.pdf (440.4 KB)
some here.
Please share with me if you found them.
Regards
I managed to configure the device and connect it to the LoRaWAN network.
We had a problem with DevEui and AppEui because the device has been sent to another costumer before us and they changed all Euis (that was the reason we could not recieve any data before).
Ok, now the device is sending data.
The payload, btw, is something like this:
"uplink_message": {
"session_key_id": "AXvJaCvwkXwol6lWLvYbSg==",
"f_port": 1,
"f_cnt": 13,
"frm_payload": "ABIojwYMAAAAAAAAAAAAAAAAG/E=",
So, the payload seems to be ABIojwYMAAAAAAAAAAAAAAAAG/E=
It does not appear to have anything in common with the ASCII coding as described in the manual.
It is also true that the device sends like 6 messages in row, one after another.
We are guessing that the payload could have been splitted in these 6 messages, but it’s still a strange message.
Have you already seen something like this?
Thanks a lot in advance.
I’ll compile the document in next days since i’ve almost reached a result.