-
Notifications
You must be signed in to change notification settings - Fork 9
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Report working/non-working receivers #4
Comments
Hi Bismosa Thanks for the greetings and the discussion of low battery behavior, it's very helpful. Can you confirm if your sensors are 433 MHz (like this project) or 2.4 GHz? |
Hello! I have exactly the same sensors as shown in the photos. I observed the sensors with an RTL-SDR (DVB-T Stick) and the software SDR Console. However, I do not know how accurate this information is. The stick is not calibrated. I have tried with your installation instructions: I also tried it under Linux on my Raspberry (Raspian Buster): I also tried to load it in visual studio code. Maybe that can be compiled with PlatformIO as well. I think I still have a lot to learn here. :) Regards |
Understood, thanks for checking. I added manual instructions to the readme so the premade hex (.ihx) file can be flashed. |
Hello!
Have i missed something? I have double checked RX/TX and have also changed them. Regards |
You will have to cycle the power to the target, so leave 3.3V disconnected at first, then run flash command, and connect 3.3V power once it says waiting. |
Many thanks for the support.
|
Okay that's good, the flash program is reading the chip. Just repeat power cycling and it should work eventually. Often I have to retry about a dozen times. I think the tx/rx pins sometimes leak power to the board, we should really be using diodes to stop this eventually. |
If that does not work, it sometimes helps to just specify the -e flag for erasing chip. After that is successful then flash hex file as before. |
I didn't get any further than this:
I also had no success with the erasing flag. I think I'll have to rework the connections first. I will try it the next days. |
You might check in with this issue in a few days and see if the other user got it working using the stc isp program: |
Hello! I flashed a sensor successfully! I have tested with some diodes (1N4148). no success. Also i have modified the command. I need only a few attempts: First i have erased the Chip with the command:
Than i have flashed with this command:
Now i will try to detect the messages. It doesn't appear to be a known protocol from my receiver. Regards |
Thanks for testing and pointing out problems/solutions. |
I have now tested the signal reception. No success. The receiver cannot detect a usable signal. I also get something different displayed with each reception. Actually, radio messages should always be the same, right? I'm not entirely sure if my receiver (Signalduino) supports the protocol. I looked at the signals with my SDR receiver. Send long when the tamper contact is opened Not consistent when the magnetic switch is operated. I pressed the magnetic switch 5 times: Here is a comparison of the radio signals Since I don't know whether it's the receiver or the transmitted signal, I can't get any further at this point. I also tried to analyze the signal with the "Universal Radio Hacker". Here is a short example. Let me know if i can help with something. |
Okay, I'm reviewing SIGNALduino to try comparing to rc-switch timings. However if it was more than two repeat transmissions I can not see it on my oscilloscope because memory fills up. I have attached a firmware that I think uses the stock timings as read by Tasmota but I have no idea what protocol it is supposed to be. Could you please try it while I check on other options? |
Ist there anything logged from the Signalduino if you Change from closed / open? |
Hello, yes. I get this log:
More Info with Verbose 5:
|
@bismosa |
The reception works well, but the sensor sends open and close within a very small timespan. I haven't found any debounce function in your code. |
@mightymos We have noticed that no pull-up is activated on the reed contact. this is missing in the code. |
Can you increase REPEAT_TRANSMISSIONS I think the First transmission can't be received by a receiver, because it needs some time to "wake" up. Increasing the number of transmissions would solve this. |
@bismosa @sidey79 I am going to try to finally capture original firmware pin behavior with my DS1052E and this program soon: However, I looked at the ASK pin quickly tonight on oscilloscope and it always sends a sync pulse followed by 24 bits, then another sync pulse along with 24 bits on retransmission, etc. I can try combining data into one package however and see if they are properly interpreted at my receivers. I disabled low battery packet for now just because it was making testing cumbersome. |
...
Four is enough. I also moved logic from the interrupts to main loop and then was able to add a very basic debounce (just a delay). If a better debounce is needed I will have to do more work. I haven't looked at your code now, but debounce can bei done via a microseconds calculation from the last isr call.
This isn't needed, we can work with separate transmissions.
@bismosa |
already done: RFD-FHEM/RFFHEM#1152 (comment) Works much better now.
|
v0.3.1 doesn't work for me. Only if I actuate the manipulation contact when applying the power supply does the LED first flash when the contact is released. But nothing is sent. I just bought a cheap logic analyzer. |
Try the v0.3.2 and possibly check out release notes. In any case, I think the firmware was getting stuck on the check for tamper closed on startup. |
I just did a short test. Thanks for the support! |
I've tested a little more now. Now I can receive the signals perfectly. I compared the signals again with my logic analyzer. I noticed that the original firmware repeats the signal 20 times. See Files (saleae Logic) here (Compared stock Sensor and v0.3.2): I also checked when the LED (bottom line) lights up. This lights up continuously during transmission . I think the new variant (LED after sending) is also good. |
Thank you, that is very helpful. I have no idea why the startup tamper switch check would get stuck on my 101 board (which mailed with no tamper switch installed). Does your 101 board have a tamper switch installed? I have a Rigol DS1052E and apparently pulseview is able to capture traces over usb to the computer. So hopefully if people sacrifice a sensor for reflash and it does not work with their receiver, they can again reflash with one version of my firmware having original timings to again resume using sensor. I will compare to your captures as soon as I can. |
stcgal flashing program will tell the part number. So I assume the startup tamper check problem is associated with some difference between stc15w101/104. |
The problem was that STC15W101 parts have a unique id stored at the end of flash space. Please try v0.3.3, the radio timings should not have changed. If v0.3.3 seems okay, I will also start adding versions with stock timings. |
I did a short test. I'll try to do more tests soon |
Thanks for the short test. This seemed to be a feature some wanted but could discuss default settings in the future too. |
Works. I like the feature. Everything seems to be working. With the receipt of the radio protocol I will have to ask again here At the moment I can receive all messages. As with the original firmware. I have now also flashed another sensor to test. this had a missing inductance directly in front of the antenna (ex works). I just replaced it with a solder point. So I can still test with the sensor near the receiver antenna. Let me know if i can help. :) |
Thank you for checking things. Using your logic traces and my oscilloscope I have recovered stock timings. The sonoff bridge rev2 seems to require many retransmissions to accept messages. I am not able to see all retransmission myself. |
Yes. I can confirm. At least with the one sensor I tested. Here is a recording: Here is the file: |
Hi there, I tried the 0.33 version and it seems to be working properly on my 104-based sensor. With respect to the 20x repeat, having deployed these throughout my house I have found the range is highly variable based on ductwork, walls etc.. What I find is that there is a 'grey' area where about 50% of the signals are received and I imagine that the more it repeats the more likely the signal is to get through. This would be harder on the battery, but means you wouldn't need multiple receivers to get coverage (I use one per floor, but I still have a few weak areas) With the tamper open, I get a repeat tamper signal every 20s. This is a great feature. A repeat battery low signal would be handy too, if that's possible. I did a bunch of testing with a variable power supply and it seems like the stock firmware sends the battery low only once when the voltage transits a certain level, if the voltage remains low, it doesn't send again. I don't know if you've implemented the heart beat - with reed closed and tamper closed I don't seem to get anything after the last change of state signal (I waited for 10 minutes). I think I have some 101-based sensors as well - the first batch I bought had no tamper switches so I assume they are 101s (they are mounted on doors now, and I haven't taken them down to check). If you need me to test on those, I can. I also have some extra 104-based sensors (with tamper), so if you need some extras for testing I could likely send a few your way. |
Thanks @bismosa I changed some of the startup and guard times in the latest release but protocol timings should be identical. I can see it might get pretty annoying supporting different configurations, but hopefully as more people test with their receivers we can see if this firmware is reliably detecting events and sending packets. |
Thanks @brandondb1 that's very helpful to hear about testing conditions. Ok to the point... Also what specific receivers are you using? |
@brandondb1 However I will re-enable soon after I get some feedback with testing other stuff, it seems to be a popular feature. |
Extending the functionality of these devices is great. One of the reasons I chose them is that they have a 'closed' transmit function as well as just an 'open' function, which many do not. The more we can make them 'stateful' the more useful they are!
I'll test the new version today or tomorrow and give you some feedback.
I'm using Sonoff RF Bridges, I have the R2 (with the bare metal antennae, rather than the black insulated ones on the PC board).
|
So with the heartbeat mode packet count version of 0.34 on a 104 version, it flashes fine, neither the tamper or the reed switch work (i.e. it doesn't transmit when the tamper is open or closed, or if the magnet is present or not). I don't know if that was intentional or not. It does transmit a packet every 21 seconds (and sometimes a second one 3 seconds later) if it's just left alone. The code in the packet increments with each transmission. Here is the log from the R2 sonoff running Tasmota: 14:30:24 MQT: tele/VirageBridge/RESULT = {"Time":"2023-02-04T14:30:24","RfReceived":{"Sync":10180,"Low":340,"High":990,"Data":"09DBB9","RfKey":"None"}} |
@brandondb1 it's difficult to fit both interrupt and heart beat features in under 1kb, so yes intentional. They are pretty limited on total transmissions per hour. What version of the R2 do you have? Thank you for the log data, I'm taking a look. |
I have now tested v0.3.5
The LED lights up for a relatively long time (during transmission?) ReedTripRadio_StockTimings.ihx Sending Time is very long. Sending is in three blocks of 20 each. I haven't tested further yet. Unfortunately I don't have enough time. Btw...a few comments to the "federal register for alarm and periodic transmission above 70 MHz" An empty battery can trigger an event, right? A temperature sensor also transmits periodically? From the article: It seems that the transmission power is also a decisive factor. But even if periodic broadcasting is allowed, I'm not really a fan of it. With the number of sensors I have, too many signals would overlap and probably only rarely something correct would be received. Just my opinion. :) |
Ok, I will make useful changes to the battery/alarm behavior in the future, but focus on the packet count for right now. Do you think the RFD-FHEM people would be willing to support the packet count byte or should I remove it/make it optional? @brandondb1 does having a packet count (next to last byte, so reed open/close would show 0A, 1E, 2A, 3E and so on) mess up your smart home parsing of messages or how does that work (see v.0.3.5)? |
In general, we make the received data available to other so called modules. The module which interprets the data focuses on appliances which normaly user this chip. If you want to send other data, it's may bei better to use anorher protocol. |
@sidey79 Understood, thank you for the clarification, and I'm reading your protocol example, thank you! |
I use the first 5 characters of the ID string as device ID, and then parse out the last character to figure out what the device is doind (e.g. open or closed). It would be easy to limit the ID string to the first 4 characters, my only observation is that in noisy places this reduces the complexity if the ID, and therefore increases the chance of an accidental positive. |
I did a short test with version 0.3.6. ReedTripRadio_StockTimings.ihx ReedTripRadio_SendPacketCount.ihx
I don't think the RSSI values are meaningful. I haven't done a range test. This is very difficult in my area |
@brandondb1 @bismosa |
Closing for now...until any new issues are discovered. |
Hello!
Very interesting Project!
A few comments from my side to the Sensors:
I have running 36 sensors. At every Window/Door one of them.
It is very important to remove the original batteries! All sensors have expired and some of the sensors have suffered severe damage
I also have several defective sensors. Some of these were already not working upon delivery. The reasons are different:
In addition, I observed:
So I think it will unfortunately not be possible to transmit the battery voltage.
I use the sensors in connection with FHEM and a CUL.
All my sensors have the hardware revision DS-4 V1.0
I have a few sensors that send a slightly different ID.
Most send an ID:
1527x... e.g. 1527x3aef0
some send another:
01101F0100 or 010F0FF000
These also have different codes for
ON/OFF/DIMUP/DIMDOWN
Closed / Open / Tamper Contact / Battery
1527x... 1110 1010 0111 0110
01101F0100 1D DD F1 FD
I have no idea if it's just a different firmware.
I like the heartbeat idea. But too often the sensors shouldn't transmit, lest there be an overlap in the messages. I use too many sensors for that.
But it would be very interesting if you could use the sensors as a water leak sensor. The current of approx. 6µA here is probably too high to detect water without additional hardware.
I will try to flash a sensor with this firmware one day. However, I still have a bit to learn about how to do this. So far I only have some experience with Ardunio, ESP, Attiny etc.
In this project, the "make" on my platforms brought different errors.
Many greetings
Bismosa
The text was updated successfully, but these errors were encountered: