Forum Home › Forums › Uncategorized Issues › M-Bus
Tagged: M-Bus
- This topic has 7 replies, 4 voices, and was last updated 4 weeks ago by manjey73.
-
AuthorPosts
-
June 12, 2018 at 2:07 pm #3828MikhailModerator
Hi All,
Our user manjey73 develops M-Bus driver. This is a complex protocol, and manjey73 needs additional info to implement different use-cases. Who has such information, please share it with manjey73.
1. Device model and manual.
2. Request and response examples.
3. Communication log. There is a useful application PiiGAB M-Bus Wizard to get log.Thanks!
June 13, 2018 at 7:18 am #3829jacklondonParticipant1. OpenSource M-Bus Library (implemented in C)
http://www.rscada.se/libmbus/ , https://github.com/rscada/libmbus
2. OpenSource (Simple) M-Bus Library (in C#)
https://github.com/ananjev-a-v/MeterBusLibrary
3. OpenSource M-Bus Library (in Java)
https://www.openmuc.org/m-bus/
There is also a dedicated chapter (chapter 9) for M-Bus and Wireless M-Bus in the book “The Internet of Things: Key Applications and Protocols, 2nd Edition”
Regards
June 13, 2018 at 8:29 am #3830manjey73ParticipantSorry for my English, I use online translator
Thanks for the links. But the problem I have is not with the description of the Protocol, and with real data from the devices. The Protocol gives a greater freedom of choice of data transmission, which of them will choose the manufacturer only knows. I would like to see different types of data transmission from different manufacturers. At the moment I have only two devices and both transmit Variable data Structure.
At the moment I have implemented the processing of Variable Data Structure in the response.
June 13, 2018 at 8:31 am #3831manjey73ParticipantThere is also a problem with scanning devices, not all manufacturers lay this functionality. For example, Wesser Heat Meter does not have this functionality and does not even have an address provided by the Protocol. It has only ID and only it can be used to run a survey.
June 13, 2018 at 1:19 pm #3832jacklondonParticipantHmmm, i understand. Unfortunately, i don’t have an appropriate M-Bus device at the moment…
June 13, 2018 at 1:34 pm #3833manjey73ParticipantHope just for those who have devices with m-Bus. At least it is planned to make free drivers that work with a specific device on the logs of requests and responses of the device. It is not difficult, as little changes there.
March 28, 2024 at 4:52 am #14294root_busParticipantI am working with the implementation of mbus protocol in energy meters. I have finished implementing it. I am using mikroe mbus master click board as master transciever and onsemi NCN5150 as my mbus slave transciever. I am facing an issue with obtaining the correct response as long frame telegram. Some of the bytes of my long telegram randomly changes after it is transmitted from mikroe master card. I am using an open source mbus master software by DECODE and using a PRCAB i extend my rx, tx signals to PC. When i am connecting my PRCAB with the rx, tx pins of my slave, everything is working alright on mbus master software as well as Docklight. But when i am taking my rx, tx signals via MIKROE mbus master card, randomly some bytes lose their original values on both the softwares.
I tried checking the hardware side, the rx, tx pins are connected ok; the baud rate, parity and stop bits is also set correctly. i also tried varying the time it takes (after recieving its full query) to start sending the response. i checked it for 33 bit period for all baud rates and other values are 11, 22, 44, 55, 66, 77, 330 bit periods. (After a query is recieved the slave will wait for some time delay after that it will start sending response. I checked it with 11, 22, 33, 44, 55, 66, 77, 330 bit period for all baud rates)
Still my problem remains unresolved. Help me out here.
March 28, 2024 at 6:10 am #14295manjey73ParticipantMaybe the bytes don’t change randomly, but in places?
There is a parameter in the protocol, I don’t remember exactly now, which speaks about direct transmission or reverse.
-
AuthorPosts
- You must be logged in to reply to this topic.