Hi. Which analyzer can label bits (1 or 0) in such a protocol?
This is a temperature and humidity sensor protocol from a weather station operating at 433.92 MHz.
This is a temperature and humidity sensor protocol from a weather station operating at 433.92 MHz.
@vendim Do you happen to know what specific protocol the data follows? If you have a datasheet of the sensor, feel free to share it as well.
1 Like
This is a sensor from such a weather station WS1066:
The board in the sensor is marked as TX4041-01.
The sensor broadcasts its data every 30 seconds. One session consists of two identical packets in sequence, such as in the first screen. These two packets are followed, after about 400 ms, by 0 to several short pulses. If the temperature and humidity have not changed since the previous session, the packets themselves will be exactly the same as in the previous session. But the “tail” (the pulses at the end) change. Why these last pulses are needed I don’t understand. As for the packets themselves, I understood part of the purpose of the bits. It is necessary to consider wide pulses as 0, narrow pulses as 1. The packet preamble is always the same. The data is encoded in 57 bits. The first 12 bits are the sensor ID, which is generated randomly after each power switch of the sensor. They remain unchanged until you change the batteries in the sensor. The next 12 bits are the temperature. They are converted to degrees Celsius as (binary number - 400)/10. The next 8 bits are humidity. Then bit #34: 0 - power level is good, 1 - low battery level. Bits #35,36 are the transmission channel number. The weather station supports up to 3 external sensors. 01 - №1, 10 - №2, 11 - №3. The purpose of the other bits I could not understand, but according to the description of all other protocols of other sensors there should be CRC. I have not found any information about the protocol of my sensor in the Internet. I need an analyzer to quickly visualize 0 or 1 bit to understand how CRC is formed. It is very difficult to write out 0 and 1 on a piece of paper every time using the Logic 2 picture.
Translated with DeepL.com (free version)
Can you upload sample capture files (*.sal)? Hard to tell from screenshot what decoder(s) might work.
1 Like
Here are a few examples:
Sample1.sal (49.7 KB)
Sample2.sal (39.6 KB)
Sample3.sal (38.0 KB)
Sample4.sal (15.3 KB)
Sample5.sal (21.6 KB)
The start combination (preamble) is followed by 57 bits of useful information. Pulses of positive polarity. The pulse width determines 0 (wide) or 1 (narrow). But the pause between pulses is always approximately the same.
Unfortunately, the provided samples don’t appear to be a typical/standard format, so would likely need a custom protocol analyzer to be developed.
See the Protocol Analyzer SDK for more information.
Note: you can also export the digital data to *.csv file, and use a spreadsheet (like MS Excel) and/or write a custom python script to manually analyze the waveform, too.
Finally, you could use the Simple Parallel Analyzer where you set both D0 and Clock to Channel 0, and then develop a High Level Analyzer (extension) to process the output generated from the simple parallel analyzer.
In your case, I’d suggest setting Clock State to Rising edge, as it appears that the ‘bit’ pulses are either 1.5X or 3X vs. the ‘sync’ pulses at the beginning of the frame, and there is a 15X space/gap between the ‘sync’ and ‘data’ phases within the frame, and a ~30X ‘idle’ between two frames.
Thus, all of the timing appears to be defined relative to the time period between two rising edges:
- A ‘sync’ pulse: ~970 us
- A ‘short’ bit pulse: ~1.46 ms
(~1.5X the 'sync pulse) - A ‘long’ bit pulse: ~2.92 ms
(~3X the ‘sync’ pulse) - A ‘space/gap’ pulse: ~14.6 ms
(~15X the ‘sync’ pulse) - A final ‘end’ half-pulse (??)
(to return back to ‘idle’ state … ??)
Total: 8 ‘sync’ + 1 ‘space/gap’ + 56 ‘data’ bits in a ‘frame’ (?)
1 Like
Thank you.
Unfortunately I don’t know Pyton, and I haven’t studied Protocol Analyzer SDK before. Now I’ll have to figure it out.
I tried to develop an extension for protocol analysis, and I managed to detect 1 and 0.
But I can’t figure it out. How to make it so that instead of “bit(value=0)” just “0” would be output, and instead of “bit(value=1)” just “1”. Is it possible?
The archive with the files is attached.
WS1066 Weather Station Sensor Protocol Analyzer.zip (15.2 KB)
Review the example at:
In particular, review more closely the result_types variable (which will configure how results are displayed in the waveform view), as well as confirm you’re returning the desired value(s) from the decode() function.
The result_types variable configures the display formatting:
result_types = {
'mytype': {
'format': 'Output type: {{type}}, Input type: {{data.input_type}}'
}
}
And the decode() function returns a (list of) AnalyzerFrame object(s), such as:
def decode(self, frame: AnalyzerFrame):
return AnalyzerFrame('mytype', frame.start_time, frame.end_time, {
'input_type': frame.type
})
So, in your code – I didn’t see any result_types variable defined, so you might try defining one:
class Hla(HighLevelAnalyzer):
result_types = {
'bit': {
'format': '{{data.value}}'
}
}
… assuming you only want a simple ‘1’ or ‘0’ value displayed in the bubble-text.
Also, you shouldn’t need to convert bit_value to string object in the returned AnalyzerFrame – as the display formatting is handled with the result_types format string above, so I think you can simply do:
'value': bit_value
Instead of:
'value': str(bit_value)
1 Like
Thank you so much! Everything worked out as planned!
I don’t know how to publish the analyzer, so I’m just attaching it to my post. Maybe someone will need it.
WS1066 Weather Station Sensor Protocol Analyzer.zip (15.3 KB)
@vendim This is fantastic, and thanks for sharing your analyzer source code! I’d love to have this posted to our list of Community Shared Analyzers below.
There are a few requirements summarized in the link below that need to be met beforehand (one of which is to post your analyzer to GitHub).
Feel free to let me know once you have a GitHub link to share for your analyzer and I’ll be happy to get that reviewed before we post it.