 Notice. New forum software under development. It's going to miss a few functions and look a bit ugly for a while, but I'm working on it full time now as the old forum was too unstable. Couple days, all good. If you notice any issues, please contact me. |
Forum Index : Microcontroller and PC projects : Don't ignore zero...
| Author | Message | ||||
Grogster Admin Group  Joined: 31/12/2012 Location: New ZealandPosts: 9757 |
Call-bell system for a house with six or so residents. Got a call from the staff saying they were getting random calls for room-7. Very interesting, as they don't HAVE a room-7. Check code. Buttons for rooms 1-6 are saved in a one-dimensional integer array - BTNS. BTNS is a 32 slot array. Position zero is not used. So, my first thought was that BTNS(7) had a duplicate code in it or something. Call in on the site, stop the code with CTRL-C, ? BTNS(7) - result was zero. Hmmmmmmm. Ran a code to list ALL the "Learned" buttons. BTNS(1) to BTNS(6) are all valid integers, BTNS(7) is zero. Hmmmmmmmm. Bollocks......   I had forgotten about ROUGE transmitters and a zero code. If a transmitter NOT part of the house transmits but within range of the system so it receives the transmission on 433MHz, but has a ZERO code, the system detects it, responds to it, looks up the BTNS array, and finds that the SEVENTH element in the BTNS array - is zero. It therefore announces that room SEVEN has called - even when it hasn't. I had made no allowance for a rouge 433MHz transmission with a code of zero. Obviously, some garage door openers in the area are perhaps issuing a zero-value code, or some other code that THEY recognize, but that other detectors will see as zero. With no allowance for this......well......opps.   A simple IF N=0 THEN dealt with the issue, but don't ignore zero!!!  Smoke makes things work. When the smoke gets out, it stops! |
||||
| Tinine Guru  Joined: 30/03/2016 Location: United KingdomPosts: 1646 |
Rouge transmitter? More of a lavender guy myself (Rogue?)  |
||||
| robert.rozee Guru Joined: 31/12/2012 Location: New ZealandPosts: 2466 |
the earlier 433MHz transmitter fobs used jumpers to set the code, and, of course, shipped with all the jumpers left open (code=0). as i recall the devices had up to 12 code select pins, where each pin could be tied high, low, or left open. that is 3^12 = 531441 possible combinations. but setting a code required opening the fob and (randomly) adding solder blobs - i suspect most fobs just remained set to the default of 0   (from: https://community.home-assistant.io/t/how-to-generate-arbitrary-broadlink-rf-code/22430) with the arrival of the EV1527, each having a random OTP code set at time of manufacture, this little 'security oops' was closed! cheers, rob :-) addendum: both EV1527 (OTP) and PT2262 (jumper programmed) devices transmit 24-bit packets of data. for the EV1527 this consists of a 20-bit code + 4-bits of button data. with the PT2262 each pair of bits encode a 3-state pin (high, low, open); see page 7 in the below datasheet: https://datasheet.lcsc.com/szlcsc/PT2262_C16390.pdf Edited 2022-05-31 23:04 by robert.rozee |
||||
CaptainBoing Guru Joined: 07/09/2016 Location: United KingdomPosts: 2171 |
... which is why you should always encrypt your transmissions. eliminates crap transmissions. I have a couple of hundred HC12 slaves out there in various snooker hall installations. All encrypted, never a dodgy comm recognised by the system. plenty of traffic on the channel - all logged along with the sh*te which is duly ignored. |
||||
 Print this page |
 |
The Back Shed's forum code is written, and hosted, in Australia. | © JAQ Software 2025 |
