Esp32 433mhz communication

[meneldor]

Could you share the config? I still cant figure out how to tune it to read 2000bps from RadioHead.

[Deouss]

I am just transmitting. I guess receiver should automatically translate the source signal without any tuning.
It is up to you how you parse the bytes. It is interesting what is maximum transmission frequency with given carrier frequency.
Can we transmit 80Mhz over 433Mhz carrier?

[PeterR]

Transmit ok, receives is another thing
All the examples I have looked at suggest that <2400 bps is about as far as you can go with these modules

[meneldor]

I just want to receive one a float as string once every minute and dont know how to do it RMT is too complicated for me, and all the examples are only for how to read NEC codes, so im gonna adapt the Arduino library for my needs.

[Deouss]

I just want to receive one a float as string once every minute and dont know how to do it RMT is too complicated for me, and all the examples are only for how to read NEC codes, so im gonna adapt the Arduino library for my needs.

I think in such case you can use RMT or SPI just fine. Arduino library probably wraps everything in its own protocol which makes the whole process slower and uncontrollable. I'd like to also test NRF24L01 with larger data like video.

[PeterR]

Agree, suggest you use SPI, probably a lot easier than RMT.
The libraries tend to add a lot of complexity.

I would not send ASCII string, send the raw 'binary' value.
This is a bit bashing/shifting problem. You need to be comfortable with binary & hexadecimal and how data is represented in memory.

Suppose you want to send a single byte reading of 10 decimal. In binary that is 00001010 (as 8 bits).
For each bit of data to transmit you should send '0001' for a '0' bit and '1110' for a '1' bit.
So the reading 10 becomes:
0001 0001 0001 0001 1110 0001 1110 0001
0 0 0 0 1 0 1 0

The transmitted sequence of bits (representing the value 10 decimal) is:
0001 0001 0001 0001 1110 0001 1110 0001
Converted to a byte (uint8_t) array we have:
0x11, 0x11, 0xE1, 0xE1

So you could politely ask the SPI MASTER driver to output the above array at a very slow bit rate.
You could simply toggle the GPIO and forget about SPI or RMT

Code: Select all

for(i=0; i<bitPatternLength; i++)
{
   if(bitPattern[i]==0)
      SetGPIOLow()
   else
      SetGPIOHigh()
   WaitFor(1mS)
}

Send 3 time. Use the last value working back.
When waiting do not 'sleep', check the esp timer (sleeps are quantised badly for your purpose).

Your detector should look for transitions between 1 & 0 and then decide (based on what it saw before) if it was mostly 0's (in which case the data bit is zero) or 1's.. you get the idea.
It gets a little more complicated as you could have a very short 1->0 which you would want to ignore.

Run the test 'wired' until you can receive what you sent.
Hope that helps.

[Deouss]

I think he can send whole bytes over SPI.

Something like:

float t;
...
memcpy(spi_buf,&t, sizeof(float));
...
transmit_spi(); //bit length is sizeof(float)*8

[meneldor]

Thank you Peter! I badly needed that "foundation". I'll start from ground zero.
Regarding SPI - could it be used with a RF module?

[PeterR]

I think he can send whole bytes over SPI.

Indeed. Most examples encode 3:1 however. I'm not smart enough to argue why not & its only a small extra step. Actually one reason may be that it gives a '1' in all even when data is 0 and so trains the RF. Also I suppose you can lock onto a signal easier.

Code: Select all

Regarding SPI - could it be used with a RF module?

Of course, but only for TX. All you are telling the RF module (essentially) is are you on or off. 0 or 1. So anything which you can get to convert regular 'data' (variables, arrays etc) into a sequence of bits is there for you to use.
The process is called serialisation.
SPI is normally used as synchronous transfer (the SPI bus includes a clock). So the receiver uses the received clock to figure out if he is seeing a 1 or 0.
In your problem SPI can be used to send but not to receive. There is no clock signal.
You have what is known as an asynchronous stream of bits - no clock signal.
You will have to write code to sample the bits as detailed. This is why the RMT may (I have not used it for RX) solve a few problems.
Another asynchronous device is the UART (clue is in the A...).
Key point is does UART give adequate noise imunity? I don't know how often the ESP UART samples & so could not tell you if its good enough. Maybe on short links with handshaking. Maybe.
A UART (without clock) uses start and stop bits to 'frame' the data. So the receiver can 'lock' on as he is given a signal that data is comming.
BTW the 3:1 encoding also helps detect the asynchronous data stream.
You may have more fun with a UART but it does come down to how the ESP works and if the default RF output matches UART idle.
I suspect that it does not work else some examples would use that approach.
You may also have to add an invertor between RF and UART. Late so I'm not going to check but its good reading for you on ASYN/SYNC serial protocols.
Good luck

[Deouss]

I heard about problems with reference clocking but I think on receiver it is important to sample data with frequency at least twice higher than source and then parse the bits with some error correction.
Also I thought syncing is done automatically by receiver which usually has TTL level output that allows to hook up the signal to serial decoder. I'm guessing all those speeds are RS232 and similar.