RF Receiver (315MHz&433MHz)

NETMF & Gadgeteer
1

I need little help with connecting RF module to FEZ(FEZMini)…
I using NT-R03C RF module. Any idea how connect it to FEZ board?
Im try use PinCapture but it do not work:


uint[] buffer = new uint[100];
PinCapture pCapt = new PinCapture((Cpu.Pin)FEZ_Pin.Digital.Di9, Port.ResistorMode.Disabled);
while (true)
{
    if(pCapt.Read(false, buffer, 0, 10, 10000) > 0)
        Decode(buffer);
}



private void Decode(uint[] buffer)
{
    Debug.Print("Decode:" + buffer.Length + " bytes");
    foreach (uint item in buffer)
    {
        Debug.Print("Data:" + item);
    }
}

I don’t have oscilloscope to mesaure frequency and analyze data. All informations which I have is:

[quote]The whole data packet is composed by 24 periods where the logical “0” has a time duration of about 600 µS and the logical “1” is about 1200 µS, so when the Parking Sensor is powered, typically through the reversing lights, it starts to transmit a series of 3 bytes (24 bits) many times per second.
The 3 bytes sequence contains the address and the data (distance from the obstacle) detected from each ultrasonic sensor, so, since the ultrasonic sensors are 4, we will have 4 sequences of 3 bytes repeated over time, one for each ultrasonic sensor.
The first byte is composed by 2 nibble (4 bits), the first nibble identifies the ultrasonic sensor (0 = A, 1 = B, 2 = C and 3 = D) and the second nibble is complementary to the first, in order to verify the integrity of the data received.
The second byte, as for the second nibble of the first byte, is complementary to the third byte.
The third byte contains the distance detected expressed in centimeters.
So, if the ultrasonic sensor B detects an obstacle at 83 cm, the sequence is: 30 - 172 - 83 (0001 1110 - 10101100 - 01010011).[/quote]

Any hint how I can get data from RF module? I know that FEZ can send data trough RF because Im see some code snipet, but can also read/receive data trough RF? And if yes how?
Thanks for any help and hint’s.

2

Still looking for solution :slight_smile:
New infos. Long time ago Im buy on ebay few “433Mhz RF link kit for Arduino/ARM/MCU” complets(RX&TX) which as receiver use KXDJS2002.5 module. Im try connect it to original device but didn’t receive signals. Then Im little turn “frequency selector” part on receiver(around one turn out) and it is start receiving data. So it must use 315MHz.

Another thing is that this communication on original device is not related to RF module. It use digital pin which is connected to RX on RF module OR digital output on REMOTE device. So same communication can go trough wired connection or RF connection. So I need implement Digital input which can read this protocol. Exactly I need 2 same pins.

Arduino have for this VirtualWire library. Can something this be done in .NETMF? Maybe with using RLP?

3

Your device is made in China, send the supplier an e-mail and ask them what standard they use for digital data transfer.

4

Im 100% shure that they don’t use any standard for comunication… What I think that I need is capturing digital input. “Communication protocol” has been already hacked.
Periods time duration is described in attachment.

5

As Im describe comunication few post up here is also how look whole data packet.

6

You could use PWM /capture compare to sort out the 1’s and 0’s.

7

Sorry but I don’t know what you think :slight_smile: PWM is for output and not input :slight_smile:
Im try PinCapture but do not work.
P.S. This are not miliseconds this are microseconds. 1200us = 1.2ms, 600us = 0.6ms. So I think PinCapture can’t capture changes with that speed…

8

Dejan,

PinCapture appears to be for an event so I guess its too slow. your best bet would be to try asking the supplier.

EDIT: You could try using 2 pins setup as interrupts, one rising edge, and one falling edge.

EDIT2: Just throwing out ideas. Is it CAN bus related?

9

This guys probably are using FSK (Frequency Shift Keying) to go on the air, obsolete now. You can find some module here. I used rf modules from this people many years ago and they worked nice since many year. Check if you can find some useful info.

http://www.aurelwireless.com/en/radiomodem-data-transceivers/

10

Thanks for your help and time. It do not use CAN bus, also do not use Serial communication. It just “send” digital pulses logical 0 & 1 in sequence. Im try two InterruptPorts but do not work.


public RF433()
        {
            InterruptPort _high_pin = new InterruptPort((Cpu.Pin)FEZ_Pin.Digital.Di9, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeHigh);
            _high_pin.OnInterrupt += new NativeEventHandler(HighPinDetected);

            InterruptPort _low_pin = new InterruptPort((Cpu.Pin)FEZ_Pin.Digital.Di8, false, Port.ResistorMode.Disabled, Port.InterruptMode.InterruptEdgeLow);
            _low_pin.OnInterrupt += new NativeEventHandler(LowPinDetected);

        }

        private void LowPinDetected(uint port, uint state, DateTime time)
        {
            Debug.Print(time.ToString() + " Low Detected:" + port);
        }

        private void HighPinDetected(uint port, uint state, DateTime time)
        {
            Debug.Print(time.ToString() + " High Detected:" + port);
        }

RF module work and output data because when I unplug it from FEZMini and plug it into PIC work normaly.

dobova: I can’t use any other RF receiver. Why? Because Receiver is not important because I must decode digital signal which can be received also by wire(same signal as I get from RF module), so RF module here do not make sense. Problem is how capture this “fast” signal…
In next days I will try capture it on STM32 board with native code(I hope I can make some example because this will be my first native example)…

11

debug.print when you’re trying to do timing critical stuff is not a good approach. you’re at a minimum going to have to pump a set of samples into an array and look at it after a few seconds or something, otherwise you’ll have GC stepping on you.

But you say it just doesn’t work; perhaps you could expand on what doesn’t work and why you think that it doesn’t? Do you not get any data?

12

Brett GC is not raised because Debug.Print() is never called…

13

If you use the interrupt method to detect edges you also need to use a timer to sort out the 0’s and 1’s.
Note: PinCapture is sub mS.

14

What is wrong with InterruptPort example which Im post few post up?
Events LowPinDetected and HighPinDetected is never raised. So I don’t see why I must use some timer?

15

Because 1’s and 0’s are pulses it just the timing is different :).

16

Sorry but I still don’t understand what you wold like say that I must do :slight_smile:
I know that 1 and 0 are pulses with different but InterruptPort must be raised as described in next image, but none of both port do not raise ANY event.

17

Are you sure you are connected to the correct pins on the mini?
Are you sure the pins are initialised and ready to receive?

EDIT: Is power connected to the receiver?

18

So if your interrupt routines are not firing either the pin is not connected as DaveF says, or there’s some other issue with code. Try a different pin and connect it to a button and prove your code should fire interrupts.

Here’s another test that will prove you have a signal where you expect it to. Create a large array of BOOLs and in a loop read the pin state and write that to your array, then when you’ve caught your array full of values print them out and if you don’t see a change from 0 to 1 to 0 at some point, there’s a more fundamental problem

19

Davef: Im shure that pins are connected except if DIP pins on FEZMini do not work(I will check later).
I think that receiver is powered. I power it from pin “5V out USB-powered 5V to 9VIn” BUT I power FEZMini from USB port and on this pin I don’t have any power source. I must check if this pin realy output 5V but probably not.
PIN’s are initialised because Im also try use InterruptEdgeLevelHigh and InterruptEdgeLevelLow but Im receive exception on start…

Brett: I will recheck all and report findings.

20

I started with real low speed sensing when I wanted to prove that the approach I was taking with the interrupt handling would work - and literally wired in a switch instead of a component that generated a pulse sequence. Then I just clicked away to prove the handling worked, in much slower rate; at least that way I could prove the concept and then all I needed to do was slot in the real bitstream and I was happy.