AmbientWeather-TX8300 & unmanaged encoding
Opened this issue · 7 comments
I have the aforementioned device and although r433any detects it and seems to be detecting the timings, it is not able to decode any of the data (from what I can tell, one of the bits may be a bit long?). rtl_sdr detects and decodes it fine. I noticed that there was an issue opened a while back for another unmanaged encoding device and the opener was able to get their issue resolved but, unfortunately, I don't understand the solution well enough to adapt it for my device.
The information as output by 01_main is as follows.
Data:
-----CODE START-----
// [WRITE THE DEVICE NAME HERE]
rf.register_Receiver(
<unmanaged encoding>, // mod
3908, // initseq
0, // lo_prefix
0, // hi_prefix
0, // first_lo_ign
1924, // lo_short
1924, // lo_long
1964, // hi_short (0 => take lo_short)
3904, // hi_long (0 => take lo_long)
0, // lo_last
3908, // sep
0 // nb_bits
);
-----CODE END-----
The timing info from rtl_sdr is as follows:
https://triq.org/pdv/#AAB10307A40F30994C80809180808081818180818180818080808080818180808081808081818080808081818181818080808180808180818181818180808181818081818080818181818080818081818180818255
(I think this should be enough to see what is occurring but can gather more data if required.)
Thanks.
Hello
Looking at code timings would be easier, like, the ones produced with rf433snif lib.
Anyway, looking at triq.org you posted, what I can say:
-
It doesn't look like Manchester coding (although it is what is guessed by triq.org)
Indeed, assuming the red means "high" and the green means "low":
We can see several sequences 'long_high'-then-'short_low'-then-'long_high'.
This is not possible with Manchester.
By the way the low signal is always of the same duration (short). This, again, cannot be with Manchester. -
Encoding looks as if being a variation of TRIBIT.
That is, it is as if...
... one bit value (let's call it '0' arbitrarily) is coded by 'short_low'-then-'short_high'
... the other bit value (so here: '1') is coded by 'short_low'-then-'long_high'
-> The 'low' is always short, only the high duration is short or long to differentiate 0s and 1s.
While infrequent, there's a few such encodings defined in rcswitch for example.
Bad news
This cannot be identified by RF433any. RF433any requires a short be followed by a long and vice versa, to identify TRIBIT.
Maybe I should bring this improvement one of these days... ;-)
RF433any can identify Manchester, too, but as said above, it is not Manchester.
Good news
rf433recv can decode it, with proper settings.
If you submit rf433snif output, I can try to work out what register_Receiver() parameters will work.
Indeed the short/high duration is not enough, I also need to see the INIT(or PREFIX) duration + I got to be sure what is 'high' and what is 'low', it is not clear to me on triq.org.
Regards, Sébastien Millet
Thank you. I have some experience with some of this stuff as I was creating hardware and firmware for RFID decoders and programmers in the early 2000s but there has been a lot of water under the bridge since then and things are not as clear as they once were. Once upon a time, I would have worked things up from scratch but using libraries tends to be more productive these days.
As you tell me that rf433recv can decode it, I will redouble my efforts and try and get it working myself. I just need to bang my head against the wall repeatedly until my brain gives in. I'll report back. If I have no luck, I'll get those timings for you. Fortunately, there is code in the rtl_433 repository to work from as well.
This is from ambientweather_tx8300.c fwiw.
1970us pulse with variable gap (third pulse 3920 us).
Above 79% humidity, gap after third pulse is 5848 us.
- Bit 1 : 1970us pulse with 3888 us gap
- Bit 0 : 1970us pulse with 1936 us gap
74 bit (2 bit preamble and 72 bit data => 9 bytes => 18 nibbles)
The preamble seems to be a repeat counter (00, and 01 seen),
the first 4 bytes are data,
the second 4 bytes the same data inverted,
the last byte is a checksum.
Preamble format (2 bits):
[1 bit (0)] [1 bit rolling count]
Payload format (32 bits):
HHHHhhhh ??CCNIII IIIITTTT ttttuuuu
- H = First BCD digit humidity (the MSB might be distorted by the demod)
- h = Second BCD digit humidity, invalid humidity seems to be 0x0e
- ? = Likely battery flag, 2 bits
- C = Channel, 2 bits
- N = Negative temperature sign bit
- I = ID, 7-bit
- T = First BCD digit temperature
- t = Second BCD digit temperature
- u = Third BCD digit temperature
The Checksum seems to covers the 4 data bytes and is something like Fletcher-8.
I'm concerned that thing about the humidity might cause problems.
This is the output from the snif. I had to lower the threshold a bit.
Signal duration: 231188 us
N LOW, HIGH
-----BEGIN RF433 LOW HIGH SEQUENCE-----
, 2748
000 1896, 3900
001 1892, 2056
002 1784, 3896
003 1892, 3908
004 1888, 1988
005 1844, 3912
006 1884, 1988
007 1864, 3984
008 1796, 1960
009 1880, 2056
010 1792, 4068
011 1728, 1996
012 1868, 1980
013 1868, 1988
014 1868, 3984
015 1808, 4056
016 1736, 1972
017 1884, 2128
018 1720, 3912
019 1888, 70120
020 12, 3696
021 4, 244
022 8, 2164
023 28, 240
024 12, 940
025 12, 232
026 12, 2160
027 12, 24
028 4, 228
029 12, 932
030 4, 220
031 12, 620
032 12, 228
033 32, 36
034 4, 180
035 28, 4
036 12, 864
037 20, 12
038 4, 204
039 72, 240
040 0, 284
041 12, 16
042 0, 248
043 24, 212
044 8, 656
045 4, 196
046 28, 4
047 12, 232
048 8, 16
049 4, 240
050 8, 584
051 8, 36
052 4, 180
053 12, 20
054 12, 836
055 28, 16
056 12, 1132
057 88, 180
058 12, 28
059 16, 232
060 12, 592
061 16, 16
062 12, 200
063 16, 12
064 12, 228
065 12, 292
066 12, 36
067 4, 188
068 20, 4
069 4, 12
070 4, 184
071 24, 20
072 12, 844
073 76, 188
074 84, 576
075 12, 280
076 12, 248
077 12, 272
078 4, 308
079 20, 212
080 64, 232
081 8, 28
082 4, 828
083 48, 4
084 12, 176
085 48, 4
086 12, 204
087 32, 4
088 12, 544
089 32, 4
090 20, 240
091 4, 560
092 16, 12
093 20, 184
094 112, 136
095 16, 0
096 76, 196
097 40, 20
098 4, 224
099 4, 260
100 16, 264
101 20, 20
102 20, 220
103 16, 16
104 4, 220
105 84, 160
106 136, 144
107 100, 560
108 12, 216
109 120, 148
110 120, 196
111 16, 28
112 12, 240
113 16, 20
114 4, 236
115 48, 188
116 28, 8
117 8, 244
118 20, 256
119 32, 16
120 4, 148
121 16, 0
122 92, 140
123 116, 212
124 24, 308
125 4, 216
126 112, 136
127 124, 180
128 108, 208
129 40, 16
130 4, 160
131 128, 168
132 92, 208
133 24, 4
134 20, 212
135 32, 4
136 28, 160
137 136, 124
138 140, 172
139 116, 192
140 24, 56
141 4, 148
142 136, 152
143 108, 228
144 12, 264
145 4, 12
146 40, 168
147 128, 136
148 132, 212
149 24, 16
150 4, 228
151 20, 4
152 24, 164
153 116, 152
154 124, 196
155 24, 28
156 12, 208
157 36, 4
158 24, 500
159 72, 204
160 12, 8
161 24, 228
162 40, 4
163 20, 160
164 124, 144
165 128, 188
166 88, 232
167 32, 4
168 4, 168
169 132, 136
170 128, 172
171 64, 4
172 12, 212
173 96, 160
174 4, 4
175 96, 180
176 88, 196
177 80, 212
178 100, 160
179 132, 136
180 132, 188
181 64, 4
182 4, 212
183 20, 240
184 112, 140
185 136, 176
186 100, 184
187 120, 136
188 144, 144
189 128, 220
190 20, 20
191 4, 220
192 76, 148
193 144, 128
194 148, 168
195 116, 188
196 108, 144
197 4, 332
198 20, 4
199 12, 220
200 32, 4
201 28, 188
202 112, 132
203 160, 116
204 152, 168
205 108, 220
206 68, 164
207 136, 124
208 144, 172
209 112, 172
210 124, 140
211 152, 168
212 96, 188
213 20, 4
214 40, 228
215 72, 176
216 24, 0
217 68, 136
218 128, 168
219 116, 196
220 28, 256
221 108, 152
222 116, 192
223 24, 8
224 36, 196
225 116, 136
226 148, 120
227 144, 196
228 84, 204
229 40, 4
230 36, 144
231 136, 128
232 132, 180
233 116, 192
234 112, 128
235 20, 20
236 4, 260
237 84, 204
238 56, 4
239 0, 204
240 40, 4
241 28, 136
242 152, 132
243 136, 160
244 120, 184
245 20, 4
246 64, 140
247 160, 116
248 152, 160
249 116, 212
-----END RF433 LOW HIGH SEQUENCE-----
This possibly also though it looks fairly different but maybe I'm just not understanding what's being recorded. There are other 433 signals around here but I isolated these to be the device as best I could.
Signal duration: 128392 us
N LOW, HIGH
-----BEGIN RF433 LOW HIGH SEQUENCE-----
, 6844
000 384, 92
001 180, 116
002 164, 124
003 144, 132
004 160, 108
005 152, 140
006 136, 140
007 152, 120
008 160, 108
009 168, 100
010 196, 92
011 188, 128
012 140, 124
013 168, 120
014 164, 132
015 152, 128
016 160, 108
017 172, 120
018 136, 152
019 144, 144
020 160, 108
021 172, 108
022 184, 108
023 168, 4
024 48, 40
025 172, 108
026 176, 116
027 168, 128
028 144, 144
029 152, 116
030 176, 124
031 164, 136
032 128, 144
033 152, 124
034 160, 116
035 164, 128
036 176, 116
037 168, 92
038 184, 136
039 136, 136
040 152, 140
041 160, 108
042 172, 112
043 176, 116
044 168, 140
045 148, 120
046 152, 152
047 136, 132
048 152, 136
049 152, 120
050 160, 120
051 160, 136
052 144, 144
053 152, 112
054 164, 116
055 160, 144
056 144, 136
057 152, 160
058 128, 144
059 124, 144
060 152, 136
061 152, 128
062 160, 124
063 160, 160
064 124, 136
065 168, 12
066 4, 10648
067 1964, 6740
068 420, 76
069 208, 76
070 220, 16
071 4, 40
072 212, 12
073 20, 12
074 188, 92
075 180, 116
076 176, 8
077 8, 60
078 220, 12
079 12, 12
080 184, 88
081 196, 92
082 248, 48
083 192, 128
084 144, 124
085 168, 92
086 188, 116
087 188, 92
088 172, 96
089 188, 160
090 4, 300
091 84, 152
092 160, 100
093 180, 100
094 220, 72
095 188, 48
096 0, 24
097 176, 116
098 164, 112
099 164, 0
100 8, 80
101 176, 16
102 4, 60
103 172, 100
104 192, 92
105 236, 72
106 168, 112
107 176, 84
108 204, 84
109 204, 16
110 12, 40
111 236, 32
112 200, 84
113 192, 108
114 188, 108
115 176, 16
116 8, 52
117 172, 96
118 180, 108
119 204, 88
120 196, 108
121 152, 128
122 152, 144
123 116, 168
124 132, 152
125 160, 92
126 192, 84
127 228, 80
128 188, 4
129 12, 56
130 184, 84
131 196, 100
132 196, 100
133 184, 108
134 168, 128
135 152, 108
136 172, 4
137 4, 88
138 180, 28
139 4, 64
140 160, 100
141 188, 100
142 180, 124
143 20, 4
144 116, 124
145 180, 24
146 0, 10604
147 2156, 20
148 20, 6412
149 32, 12
150 456, 48
151 228, 64
152 844, 64
153 212, 84
154 272, 20
155 284, 4
156 188, 80
157 200, 84
158 240, 40
159 256, 64
160 168, 92
161 196, 76
162 248, 0
163 8, 8
164 256, 20
165 204, 72
166 212, 72
167 300, 4
168 236, 16
169 232, 64
170 212, 88
171 240, 12
172 12, 4
173 220, 32
174 4, 12
175 184, 100
176 188, 84
177 292, 4
178 244, 4
179 228, 76
180 220, 72
181 604, 0
182 192, 68
183 220, 72
184 264, 28
185 276, 28
186 184, 76
187 200, 100
188 220, 84
189 220, 12
190 4, 20
191 180, 88
192 212, 80
193 252, 40
194 236, 68
195 168, 100
196 188, 76
197 224, 36
198 4, 12
199 220, 4
200 12, 16
201 204, 76
202 204, 88
203 204, 108
204 196, 84
205 172, 96
206 188, 96
207 212, 92
208 180, 0
209 16, 56
210 176, 124
211 160, 100
212 200, 96
213 188, 84
214 188, 92
215 192, 84
216 200, 116
217 160, 148
218 152, 10640
219 2024, 12
220 20, 4
221 4, 6564
222 48, 4
223 440, 56
224 224, 60
225 852, 48
226 220, 80
227 256, 24
228 532, 60
229 220, 80
230 584, 32
231 192, 68
232 208, 64
233 288, 4
234 532, 64
235 212, 76
236 192, 128
237 196, 4
238 8, 48
239 180, 76
240 204, 80
241 240, 0
242 4, 32
243 492, 100
244 180, 88
245 240, 12
246 12, 4
247 212, 12
248 32, 0
249 196, 76
-----END RF433 LOW HIGH SEQUENCE-----
Hello
About your first posting: it clearly corresponds to the description you give (Bit 1 : 1970us pulse with 3888 us gap, Bit 0 : 1970us pulse with 1936 us gap).
Issue is, I see 19 or 18 bits of data, not more.
Possibly, the snif start signal was not expecting the correct duration for the "init" sequence (too short criteria) and it started too late, stepping into the train while already in motion.
One thing is sure, an INIT sequence of 2748 us would be VERY strange (it is between short and long ; normally INIT is far above the long duration).
If you know how to update snif lib, you might change the "initial signal duration to start recording" for various other durations to get the whole signal.
Most frequently, the "init" sequence (not part of encoding, just to say to the receiver "pay attention to what'll follow") is "MUCH LONGER" than the long duration. So here, the long duration being 4000 us, I'd try to start snif after an init signal of 8000 us of 10 000 us or so. Not less than 6 000 us in all cases.
About your second posting, it clearly looks like something "not random", but does not look like an encoding either!!!??
Let me explain: normally an encoding relies on different durations to go over the radio, the decoding consisting in discriminating between different durations to end up with "0s" and "1s". Here, the durations are all too close.
See picture of durations statistical repartition:
You normally will see (with a signal carrying encoding) that durations are split in 2 categories, the short ones and the long ones. Sometimes on low signal, sometimes on high signal, sometimes (most frequent) on both. Given your description, we can expect the low signal to be always of the same length (2 000 us), the high to be split into 2 different categories, the short (2 000 us), the long (4 000 us).
In your data there is ONE duration on low signal, ONE duration on high signal!
Conclusion? I can say nothing here sorry. Maybe, the encoding is based on the signal phase? Then, the duration only won't help, as you'd need a receiving device that recognizes the phase to get the data. Or there is some sort of FM-modulation in it? Just random guessing...
Regards
Thanks for taking a look. I'll look into modifying the lib. For now, what I want to do, I can do with the SDR so I'll use that while I look into this. It's also possible the receiver is not very good. I have one on the way that is supposed to be better so I'll have another look when it arrives.