Fix data type + support variable bit lengths

[elliots]

:+1: 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.

[juhnhooo]

Hi, I've spent a long time trying to issue 32-bit codes via 433 but I can't find a way to do it.

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. This code is 24 bit, so there is something wrong. It seems that the emission of the code is cut (only send de first 24 bit)so my switches do not turn on or off.

How can I send this code 2349597568?

Thanks for all

[SiberaIndustries]

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:

./codesend 2349597568 0 0 32

[juhnhooo]

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 https://github.com/atsage/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.

[SiberaIndustries]

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: ./codesend 2349597568 1 350 32

[juhnhooo]

Hi, and thanks a lot. I have tested it on a Raspberry 2 with Linux raspberrypi 5.15.76-v7+ 32 Bit.

I install wiringpi sudo dpkg -i wiringpi-2.61-1-armhf.deb

gpio -v gpio version: 2.61 Copyright (c) 2012-2018 Gordon Henderson This is free software with ABSOLUTELY NO WARRANTY. For details type: gpio -warranty Raspberry Pi Details: Type: Pi 2, Revision: 01, Memory: 1024MB, Maker: Sony

• Device tree is enabled. *--> Raspberry Pi 2 Model B Rev 1.1
• This Raspberry Pi supports user-level GPIO access.

cd /usr/src sudo git clone --recursive https://github.com/ninjablocks/433Utils.git cd 433Utils/RPi_utils sudo make all g++ -DRPI -c -o ../rc-switch/RCSwitch.o ../rc-switch/RCSwitch.cpp g++ -DRPI -c -o send.o send.cpp g++ -DRPI ../rc-switch/RCSwitch.o send.o -o send -lwiringPi -lwiringPiDev -lcrypt g++ -DRPI -c -o codesend.o codesend.cpp g++ -DRPI ../rc-switch/RCSwitch.o codesend.o -o codesend -lwiringPi -lwiringPiDev -lcrypt g++ -DRPI -c -o RFSniffer.o RFSniffer.cpp g++ -DRPI ../rc-switch/RCSwitch.o RFSniffer.o -o RFSniffer -lwiringPi -lwiringPiDev -lcrypt

This commands don't work, it dont send nothing

/usr/src/433Utils/RPi_utils $./codesend 2349597568 350 0 32

sending code[2349597568]

/usr/src/433Utils/RPi_utils $./codesend 2349597568 350 1 32

sending code[2349597568]

/usr/src/433Utils/RPi_utils $./codesend 2349597568 350 2 32

sending code[2349597568]

/usr/src/433Utils/RPi_utils $./codesend 2349597568 350 3 32

sending code[2349597568]

/usr/src/433Utils/RPi_utils $./codesend 2349597568 350 4 32

sending code[2349597568]

/usr/src/433Utils/RPi_utils $./codesend 2349597568 350 5 32

sending code[2349597568]

/usr/src/433Utils/RPi_utils $./codesend 2349597568 350 6 32

sending code[2349597568]

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.

/usr/src/433Utils/RPi_utils $./codesend 2349597568

sending code[2349597568]

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:

/usr/src/433Utils/RPi_utils $./codesend 2349597568 --> this command send code but cut off, only 24 bits.

/usr/src/433Utils/RPi_utils $./codesend 2349597568 350 6 32 --> this command don't send nothing.

/usr/src/433Utils/RPi_utils $./codesend 12345678 350 6 24 --> this command don't send nothing.

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... I don't know what else to look at to be able to send 32-bit codes and turn on the lights with the raspberry. I have googled many solutions... I have tried several scripts... but so far I have not been able to send 32 bit codes... https://abyz.me.uk/rpi/pigpio/download.html https://forums.raspberrypi.com/viewtopic.php?t=178074 https://github.com/sui77/rc-switch/issues/303 https://github.com/sui77/rc-switch/pull/221/files I don't know what else to look at to be able to send 32-bit codes and turn on the lights with the raspberry.

Thanks a lot for all.

[SiberaIndustries]

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 ./codesend 2349597568 350 0 32 → ./codesend 2349597568 0 350 32

---

Everything you did looks correct. Anyway.. Meanwhile, I have now taken a closer look at the RCSwitch and have a few comments:

1. there are 5 different protocol definitions instead of 6 (see RCSwitch.cpp: 52).
2. I don't think its a bug, because all I did was more or less change the datatype to the correct one and add the bitlength as an optional argument (as you can see in the changes)
3. PIN 0 is correct, because it is set the same way in codesend.cpp: 27
4. https://github.com/sui77/rc-switch is used in this repo (but it uses a 6 year old commit id, so you can try to build with the current version by just replacing it) .. Might be a good idea to update this in this repo anyway :)
5. https://github.com/atsage/rc-switch and its support of 64 bit lengths would not change the result as long as the number also fits in 32 bits.

---

If its still not working:

• I have checked my active switches and I have got some from lunvon for example that requires a pulse length of 500. So also try with a higher lengths.
• Range of the receiver? TBH I bought a cheap reveiver on ebay and I have to get very close to be able to receive the sent codes (matters only once, when I am adding new switches into my environment)
• Did you forget a git pull (in case the repo is already checked out and just out of date)?

Keep us posted ✌️

[juhnhooo]

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) ./codesend 2349597568 0 500 24

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 When I use ./codesend 2349597568 1 500 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 2 500 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 3 500 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 4 500 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 5 500 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 6 500 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 0 350 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 1 350 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 2 350 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 3 350 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 4 350 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 5 350 32 --> The raspberry pi does not emit anything When I use ./codesend 2349597568 6 350 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? https://www.e-ika.com/images/thumbs/0011458_emisor-y-receptor-de-433mhz.jpeg

Thanks for all another time.

[SiberaIndustries]

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: ./codesend 2349597568 0 500 32. It works on my raspi and from the perspective of your HW it should work on your raspi as well. I don't think that there is a HW limitation because in the end the value represents just a binary signal modulation (1/0, on/off period) which gets transmitted into a radio wave signal (and now has a larger limit and nothing logically changes by changing from 24 to 32 bit length), but I am not 100% sure.

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.

[juhnhooo]

Hi, I have news about this. The purpose is to be able to control:

DIO 1.0 Ref.54760 Battery: 3V CR2032 Date code: 2004 Chacon SA Av. Mercator 2 1300 Wavre - Belgium www.getDio.com

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: 1.-.The signal is different 2.-.The lights devices don't do nothing.

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

[SiberaIndustries]

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 signed long instead of an unsigned long which decreases the limit by the half - but I have not found any so far). Try ./codesend 2147483647 0 500 32 and ./codesend 2147483648 0 500 32 for example.

[juhnhooo]

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.

[SiberaIndustries]

There is also a send.cpp in RPi_utils that you might could have tried too (probably matches with this new situation / requirements) 😂✌️ but I am not sure if it supports 32 bit as well (might be a good reason to have a look at it)