Two days decoding

Hi all
Pls i have code from device. Device is boiler … the result should be read °C or bit on, off and write on, off and change temperature . I dont no whats is this code rs485 or 1-wire or, or ? the manufacturer did not provide register and comunnicate protocol
thank you for all and sorry for my english

galmet.sal (12.7 KB)

I think you are looking at too much at once. Increase the sampling frequency and reduce overall capture to 1 second. If Channels are the only 2 with significant information, the disable the rest, and capture at the highest resolution you can. I just get the feeling that you are missing some information.

Also, can you catch the analog levels on CH & 2. That might help identify this differential protocol. RS-485 and CAN operate at different levels, also on both busses there is more than high and low, but states where the bus is undriven. The analog levels would help identify states such as undriven and the 1’s and 0’s, (key words include idle, dominant, recessive, etc)and therefore indicate protocol and framing.

If this RS-485 then you can use the Saleae “async serial” analyzer to decode, try 115200 for speed, or 9600, they are fairly common speeds these days. If it’s 485, are they using MODBUS as the upper layer protocol?

If it’s CAN then there is a protocol analyzer for that too, but that’s not my field of expertise.

The context of Boiler is a little vague, is this industrial, maritime or residential? That should also give a clue as to what might be in use.

Where are you tapping in? On the controller card, or the wire between the controller and boiler? If you are looking at the board, then you can find your way back to the transceiver, and that part number will give a good clue too.

1 Like

Hi thank you for you time … I appreciate it… boiler is in my home… i connect rj45 first cabel is with voltage 5v and secound has 0,9v na for one secound 1,2v… thank you i connect again…

Those voltages sound more like you measured them with a voltmeter.
I can help a bit more if you can catch a second waveform.

The only channels we are really interested in at this time will be

  • Ch 0 digital
  • Ch 1 digital
  • Ch0 analog
  • Ch1 analog

By looking at the analog channels we will see not only logic high and low, but two voltages. A volt-meter will see an digital signal as a partial voltage. Your bus is most idle (80% idle, gap between data burst 800ms, data burst once per second). We will probably see the bus is alternating between 1.2v and ground on the analog traces. This sounds low for a differential bus that is probably over a couple of meters of cable, I’d expect 5v -12v level. However low votage differential signals are a thing (LVDS).

The second things I see is a recurring pulse train leading up to the data burst.

If we zoom into that pulse train, there seems to be a recurring pattern, a short followed by a long

But that short pulse is not always there. If I zoom in all the way, the shortest time the bus is in either state is 20us (micro seconds), and that is a short pulse on screen. 20us → 25kHz. I suspect you might have your sampling rate set at 25kHz, and so we are missing details.

After you get your sampling rate set to something faster you probably won’t see any missing bits in the sync train, and then you may get more resolution in the actual data burst.

Once you get that better capture, you may want to turn on the Async Serial analyzer. One signal is the invert of the other. If this was RS-232 (which it isn’t, but you can look at the idling high half of RS-485) then you would put the monitor on Ch 0. I’d doesn’t cost anything to turn it on for both.

To know your baud rate, you will need to find your shortest bit time, which will be the first bit as the start. We don’t know if you have 1, 1.5, or 2 stop bits (assuming this is RS-485).

You’ll be looking at something like this (from your original .sal file)

If you want to share the new capture, I can take a look again.

Just out of curiosity, what brand controller is this that you are looking at? Ah - Galmet, seems to be a Polish brand, available through Europe.

Ou this is super …I really appreciate it… I can new capture… And Galmet … Yes this is poland brand. But this is six years old device and none suport for this device… I have heat pump in my home but now electric energy is so so expensive and i had to heat my house in Galmet… im sorry for my english :wink:

now i capture new sal now i capture with 1ms/s s this true ? thak you
galmet2.sal (5.7 KB)

Okay, that’s a lot better.

  1. Before your shortest pulse was 20us. This lead me to believe you needed to increase your resolution, nothing is that perfect at that frequency, adn we had “missing bits” in the synchronization or wake pulses. In this capture we the shortest pulses are 17 or 18 us long. You could double your sampling rate again, and you will see that things average out about 17.5us. This means we are seeing about 57khz bus frequency, so probably looking at 57,600bps for your connection rate.

  2. With this new visibility, decoding as async serial - 8 bit, no parity, 1 stop bit, I saw lots of framing errors. I tried odd and even parity, then I tried no-parity and 2 stop bits, and it seems to be happy decoding that.

  3. I also tried with CAN at the same bitrate, and that has promising framing results.

No promises ,but I believe you can start reverse engineering the protocol by looking at D3 with the ASYNC serial analyzer. configured for 57600 baud, no parity, 2 stop bits. I do see occasional framing errors, and using 4 times faster sampling rate would probably resolve that (but no guarantee).

You may see good results on D3 for CAN at 57600bps.

And your English is way better than my French (my only second language) and way way better than all my other european languages.

I think you are in a good place to sort this out for yourself now you can see bytes.

Happy hunting.

1 Like

This is perfect… and pls how i read to this with esp… i read many device and import to home assistant. How do i know what is … addres and and… this device is my black moth :upside_down_face: I think I found my ceiling that I probably won’t get over :joy: :joy: I read modbus protocol from many system megarevo 350kw fotovoltaic and this is super… and more more . but this :melting_face:
Im from Czech republic and this is incredible comunications… thank you so mutch . Have you buy me a coffe ?

There’s not much more I can help with.

Reverse engineering a bus is non-trivial. The basic trick is to look at the byte stream, and look at what is happening in the system. You already have some intuitive idea of what is happening, but you will know better than me. You have to stimulate (make changes) and then observe what happens.

It sounds like you are tapped in between a user interface (UI) and a controller on the boiler. You know that control and status are being exchanged between the two.

Your original comment suggests you are looking at temperature, and assuming there is a get and set pair of commands. You also say you can change the UI from F to C.

I would assume that the bus interface will only communicate in one unit, and being european, I would assume centigrade. The UI doing the conversion with the display software. I also assume that the temperature would be in one of centigrade, deci-centrigade or centi-centigrade sent as fixed point numbers. If the number you are seeing are over 100, then you are probably looking at something with higher resolution than centrigrade. That said, for packet desity, and who needs fractional degrees on a boiler, it would probably be centigrade.

The controller may only need a target temperature, and will respond with actual temp, and not need on/off commands.

In some RS-485 busses (if that is what this is) the differential voltage may be different depending on direction. This will help you identify the send versus receive.

There is some turn around time between a request and a response on a half duplex bus. Depending on implementation as to how fast this is, but still, the requester has to release the bus and the responder has to reply. Look for gaps between bytes.

Again, looking at voltage, this should be evident as the bus becomes undriven in the turnaround time, but may be masked on the digital channels. I have seen ST micro controllers throw a “framing error” in the turnaround time, so look for any errors on the async

Of course, if this is RS-422, then that is a full duplex interface, and you are only looking at half the communications, and there will be another pair on your RJ 45 that carries the opposite direction.

Maybe try:

1 Like

Thank you i check it…

Hi all
now i connect device and capture new sequence a with handy i take photo from display…

galmet3.sal (6.9 KB)

i change all analyze seting and nothing number is not same with display thank you ,

Now is the tough part –

What is your final goal? Are you trying to make your own display, controller and/or data logger, or just trying to repair something that’s broken? Depending on your goals, you may want to look for service manuals or repair guides online vs. trying to reverse engineer this serial protocol. In that case, it might be more important to identify the part #s for the whole system and/or key system components, and search for any technical details on those parts online.

Otherwise, trying to reverse engineer the information captured vs. what is displayed is a difficult task. You’ll probably need to take multiple captures while adjusting system settings one by one to compare data that changes vs. stays the same, and then see if the changed values can be related back to the display and the setting you changed. At this point, we don’t even know what interface you’re capturing, nor do we have a general outline of the system & components you’re trying to decode. In fact, this data stream might have nothing to do with the display, and it serves some unrelated internal system function (??)

This probably isn’t something likely to be solved within this forum, but rather by your own trial and error on the equipment being reverse engineered. I think the tool is now capturing the data and providing a reasonable ‘decode’ (at a low-level only), so it’s now up to you to figure out the ‘high-level’ format of the data bytes being decoded. To get further, you might have better luck at: (or similar forums) – reading previous posts to learn from past experiences, or asking new questions and hoping somebody out there knows more about your particular system. Also, maybe there are better non-English forums with more people interested specifically in Galmet boilers, as they may not be commonly used products within English-speaking countries (??)

For example, here’s one similar post, but nobody replied :frowning: :

Good luck!

1 Like

This project is for my monitor whats is in my boiler …
I’m learning on this device of mine and I’m trying to understand what needs to be found to make the registers readable. It’s not like I haven’t tried anything else. I tried many, many combinations of the analyzer. Maybe this port really isn’t the right one. I am in contact with the manufacturer, but he said that they will not provide any information. I’ll keep trying, maybe I’ll work on something.

1 - values may be “fixed-point” numbers, so the value will be 2^n times larger than you expected. A quick way to find the number of places after the “binary blob”, or bits for the fractional part, keep dividing by two (right shifting) until the number seems to be rounded down version of what you see on the display. The numbers in the transfer could be 2, 4, 8, 16 etc times bigger than expected.

2 - Values may be decicelcius/centicelsius, so 10 or 100 times what you expect.

3 - values might be BCD - binary coded decimal, each 4 bit chunk mapping to a digit. This used to be common in RTCs (real time clocks) and maybe numeric displays, but is probably not used in this case.

4 - the system will always communicate in F or C, probably C. The communications units will probably not change, even if you change how it is displayed.

5 - The values reported on the UI may be smoothed/averaged over time, so may differ from what you see in the protocol.

6 - I see your display is showing water temperature, house target temperature, actual house temperature. The house temperature and house target temperature are probaby local to the UI thremostat controller, not the boiler. The 78.8 and 33.9 look like number from the central heating system, boiler output water temperature, and return water temperature. There is also the 37.1c number that seems to be the temperature for the hot water to you sink and bath.
None are obvious in the decimal values you are looking at. I think you will be looking at the data for each of these to be scaled (multiplied) and spread over 2 bytes each.

I had a look. Assuming that your photos do not perfectly align with current system telemetry, I looked for pairing and scalings that made sense. Looks like they are 16 bit values, with 12 bits for the integer, and 4 bits for fractional part.

This is the sort of thing you should be looking at.

I picked 4 values that were on the display and looked for close matches in the data.

You will need to look at such values over time. If this is really RS485, you can get a cheap USB to RS485 interface, and log a days worth of data on your PC, then try various scripts to parse the packets.

Since this forum is about Saleae, I think we have taken you as far as we can. It really looks like you are getting quality data from your Saleae now, and just need to decode the data.

1 Like

This is perfect information for my learning… thank you. I will try next. Thank you

1 Like