Component sfk 433 Mhz serial for Arduino, ext.

[BenR]

Hello,

I've been having a bit of a go with some code to drive these modules and here is a simple transmit program that will allow up to 16-bits of data to be transmitted. This could form the basis of a component but I wanted to put it out there first to make sure it's what is required and that it's working for people. I hope it's compatible with the HT12A and HT12E encoder/decoder ICs as I based it on their protocol.

RF_433_TX.fcfx

(24 KiB) Downloaded 106 times

The timer interval component needs to be setup to give a decent carrier frequency, we're ideally aiming for around 38KHz (13us * 2) but on my test PIC this is running a fair bit slower around 18KHz probably due to the amount of code inside the interrupt macro. It still is working ok but I will need to tailor this for my receiver so it knows what sort of delays to expect. We could add an autobaud preamble into the transmitter code which might allow the RX code to lock on a bit better and not need precise known timings. I'll investigate this. I might just be able to use the timing of the sync pulse.

Please note I had to add antennas to my RF boards, I used single core wire measuring 173mm and just soldered this onto the antenna holes on the PCB.

Top trace is the TX data and the bottom trace is the RX data.

RX_TX.png (19.01 KiB) Viewed 2995 times

Receiver code hopefully coming soon.

[jgu1]

Wow Ben, very interesting. I know these HT12D and E. Decoder and encoder. I know you still are in the beginning of develop of this compoent, but will it also be possible to send date, string and numbers too similar to uart? Like here:
https://www.youtube.com/watch?v=b5C9SPV ... otWorkshop
I have test these tiny module, they working but the data output is noisy. Its just like the Squels not is closed and this disturb. Hope you understand what I mean

Still look forward.

Br Jorgen

[BenR]

Here's a working RX example to go with the TX example. It's not perfect and coud do with some more fine tuning but it is correctly decoding the value I'm transmitting. It does feature a bit of auto bauding based on the sync pulse width and seems to work quite well.

Thanks for the suggestions I'll see what we can do to send streams of data. You could essentially do it with what we have now only you send a byte or 16-bits at a time, maybe repeat it a certain number of times and then move to the next value. This might need additional error handling such as CRC and/or parity bit to confirm the data etc. I'll have a good watch of that vid and see what the Arduino is doing.

RF_433_RX.fcfx

(24.48 KiB) Downloaded 94 times

[jgu1]

So nice Ben Do you push it to update today so I can perform a test, I tryed yesterday, not possible

Nice weekend

Jorgen

[BenR]

Hi Jorgen,

I've not made it into a component just yet, the code I've attached is maybe the basis of a component but should compile and run just fine to do the encoding and decoding of the data. The main macro outputs the state variable to port C but this is mainly just for my own debugging and is not required.

When working with the examples change the build target to match your MCU device and then update the timer interval component to give you a good resolution. I was using a time interval of 13us. 1 / (2 x 13us) = 38.4KHz carrier.

The TX/RX pin is set via one of the top level properties as is the number of bits to send/receive.

[jgu1]

Ok Ben when I open your testprogram, I get this message and the program is loooong time to load, it start and look correct but do you think it will work?
I have update.

I have a small look at the tranmitter, which pin do I activate to send data, can´t find it, pls?

Jorgen

[BenR]

Hello Jorgen,

Sorry the FC version should be fine, we've been working on a minor update to v9 and I must have built the examples using that but nothing should cause any problems between that and the current release. Odd it's taking a long time to load.

The pin is provided by the top level properties, either click on a blank area of the panel or use the drop down at the top of the properties window.

Props.jpg (17.17 KiB) Viewed 2938 times

The pin is driven inside the TimerInt macro as part of the state machine. The TimerInt macro is called by the timer interval component on a regular interrupt driven tick.

PinState.jpg (26.57 KiB) Viewed 2933 times

[jgu1]

Hi Ben!

I have perform some test today. But no luck.

First I don´t have a BL0080 board , so I try to convert to Pic16F876, still data is comming out, but the timing, I don´t know? and this is maybe my problem, 876 maybe not so fast.
In the 876 I made a one sec flasher test, look good.
The receiver seemed to be ok with the 1937, anyway I see READY in display
To be sure nothing wrong with the transmitter and receiver (anyway, I see signal out of the receiver) I connect The output from 876 directly to the input on the 1937, but no data in display, only DISPLAY.

Jorgen

[BenR]

Hi Jorgen,

Do you have access to a scope or anything similar to help diagnose what's going on. I use the Saleae logic analysers and they are both cheap and very good.

I'm also afraid you can't connect the TX MCU pin directly to the RX MCU pin, if you look at the original image I posted with the TX example you can see the TX pin is modulated and the RX pin is clean and unmodulated. This demodulation is done for you by the receiver hardware.

I'm looking again now and it appears the receiver is collecting data but only occasionally lets a valid packet through so I'm trying to improve this now so it's more relible. We ideally need it to correctly lock onto every tx packet to receive a data stream such as a string. I'll post more as I track down the problems.

[BenR]

I've managed to tweak things and get them a bit more stable now. Rather then picking up say one in twenty packets we now receive most packets correctly. There's still the occasional loss of data due to a smaller then usual sync pulse and so the RX interrupt could be run a bit faster to overcome this.

Here we have TX data top, RX data middle and RX decoding bottom, most packets are decoded correctly but the dropped packets can be seen by the spike.

Waves.jpg (49.75 KiB) Viewed 2848 times

Here is my current RX project with a bit of debugging using pins B3 and B7. As I say decreasing the timedInterval delay slightly should make the data reception even more reliable at close range.

RF_433_RX.fcfx

(25.92 KiB) Downloaded 90 times

Next would be a system to repeat transmissions a number of times so that we can be sure of the data being received before moving onto the next value. This should be fairly easy to acheive.


Here is the modulated TX vs demodulated RX data.

Wave2.jpg (17.62 KiB) Viewed 2848 times