Fix data type + support variable bit lengths #81
Conversation
Fix negative values
Fix negative values and support flexible bit lengths
Enhanced support
|
👍 thankyou! Seems like it solves a bunch of people's issues. I'll merge whatever you think makes sense. I'd give you access to do it yourself, but it seems I've lost that ability. |
|
Hi, It seems to work because on the screen the maximum number that allows sending is 4294967295 but the emission is FFFFFF which in decimal is 16777215... I compile the code but when I try to send for example the following code ./codesend 2349597568 which is 32 bits. This code is 8C0C0380 on hexadecimal. I try to check what the emitter emits with a Flipper Zero and the code that it recovers is 0C0380 on decimal 787328. How can I send this code 2349597568? Thanks for all |
|
Sorry I didn't mention that there is a new option to set the bit length (This way I kept the fallback compatibility). This means that the default length is still 24 bit. In your case please try this:
|
|
Thanks for your answer I try it, when I put ./codesend 2349597568 0 0 32 It seems thant dont sent nothing because the switches dont do nothing and the Flipper Zero cant see nothing. Thats posible that I need this rc-switch? https://github.com/sui77/rc-switch Because the rc-switch from this repo is not compatible with 64 bit? https://github.com/ninjablocks/433Utils Thanks for all another time. |
|
I have tested it on a Raspberry 4 with raspbian 32 Bit as well as 64 Bit and both worked for me. Have you played a little with protocol or pulse length (1st or 2nd zero args)? E.g. I had to adjust the pulse length between 350 - 500 for some devices and a few required another protocol (1-6 are valid options If I remember correctly). As an example: |
|
Hi, and thanks a lot. I install wiringpi gpio -v
cd /usr/src This commands don't work, it dont send nothing When I use arguments don't send nothing. I check with Flipper Zero and It don't listen nothing. This command works fine, it sends the correct code but cut off. This code 2349597568 on hexadecimal is 8C0C0380 when I try to check what the emitter emits with a Flipper Zero and the code that it recovers is 0C0380 on decimal 787328. So if I use arguments raspberry don't send nothing for example: It is possible that there is an error in the code that causes it not to send anything? Can you say me which version of software you use to send long code (32 bits)? One thing more I use PIN 0 or GPIO17 to send the codes... Thanks a lot for all. |
|
I'm incredibly sorry, but I was on the road just now and therefore had to correct my last answer. I reversed the order of protocol and pulse length. Probably you were so fast at it that you didn't catch my correction. Please retest in the correct order and let me know. In your case Everything you did looks correct. Anyway.. Meanwhile, I have now taken a closer look at the RCSwitch and have a few comments:
If its still not working:
Keep us posted ✌️ |
|
Hi, thanks a lot for your answer.. right the correct command is: ./command Code(Decimal) Protocol(0,1,2,3,4,5,6) PulseLength(0-500) Bits(24-32) So with dis command ./codesend 2349597568 0 500 24 I receive/check with FlipperZero (0C0380 on decimal 787328, this code is the first 24 bits of 8C0C0380 on decimal 2349597568) When I use ./codesend 2349597568 0 500 24 --> The raspberry pi emits the code cut to 24 bit, it is normal because the command forces it to be 24 bit. The fact is that the hardware emits something. When I use ./codesend 2349597568 0 500 32 --> The raspberry pi does not emit anything As you can see I've tried everything... now I can check the order of the command syntax, but I still can't get the raspberry pi to output 32 bit codes... as soon as I change 24 to 32 it doesn't output anything. As I have mentioned before, I carry out the verification with a FlipperZero device and I always do the tests at a few centimeters. The hardware that I use to broadcast is the usual one that everyone uses for this type of device.This is a photo/link of the hardware I use. Could it be a hardware limitation? Thanks for all another time. |
|
Looks familiar. I am using this Transmitter + Receiver (cheap HW as you can see 😊) on the same device with a ~50mm extra ANTenna and I've tested your specific example in two different terminals again: You said that you use FlipperZero as a receiver. Do you get any outcome if you at least trying to read the RAW signals? Would also be helpful to have someone else who can approve that 32 bit values are working or not. |
|
Hi, I have news about this. The purpose is to be able to control:
DIO 1.0 When I use ./codesend 2349597568 0 500 24 with FlipperZero I see this:
When I use the original control of DIO I see this:
When I use ./codesend 2349597568 0 500 32 I don't see nothing on FlipperZero... but... When I use FlipperZero with option Read RAW I see/check that the raspberry pi sends some signal but it's different and don't work with the lights devices... I expected the same signal but longer... When I replay the signal captured with FlipperZero the lights devices switch on and switch off without problems. When I send 2349597568 with raspberry pi the signal is different and dont work it... the FlipperZero see the RAW signal but: When I use RFSniffer and I replay some signal with the FlipperZero 24 bit, the raspberry pi show the captures normally. But when I use RFSniffer and I replay some signal with the FlipperZero 32 bit, the raspberry pi don't show any captures, If I use the original DIO control the raspberry pi also show nothing. So... something happens with the 32 bits signals. Thanks for all |
|
Alright. Another signal difference might be the modulation bandwidth? Have you tried the AM270 configuration, due to the fact that AM650 is set by default? So could be an attempt to check if 1. DIO <-> Flipper still works with AM270 and if so 2. test the (new) codes with the raspi. Another try could be to test the limit of your raspi and make sure that everything works as expected (e.g. might be that there is an |
|
The first thing is that the device to be controlled is a ChaconDIO, which has a specific protocol that RFsniffer could not capture. Later I captured the signal with FlipperZero and tried to send the hexadecimal code, converted to decimal with the codesend command... right there I ran into the problem of the length of the code to be sent. Later I found the 433utils code modified to be able to send 32 bits... but despite being able to send, the DIO switches did not detect it and the FlipperZero did not detect the same when using the original DIO controller as when using the raspberry pi. But the RFSniffer and the ./codesend did send and receive the 32-bit code... I thought maybe it was the format/protocol and I found the following: https://github.com/fcrespel/chacondio10 The software is compiled and then shipped as follows: /send.sh 0 36712462 0 0 32 The first 0 is the gpio, the 36712462 is the DIO controller number (can be extracted using rtl_433 and capturing the DIO controller), the next 0 is the switch number (the dio controller has 4), the next 0 is the position (on/off) and 32 is the length of bits (I don't know if the latter is correct, but it works) With the code that generates the correct format/protocol and that when I send it from the raspberry pi the DIO switch works and the FlipperZero receives exactly the same signal as when I use the original DIO controller. In short: I have learned a lot. Although the idea of sending the 32-bit code was good and the software worked correctly it was not suitable for the DIO controller. Thank you very much again for everything. |
|
There is also a |
No description provided.