Manchester Library 433MHz again

Projects Programming
1

I am using the code below in the attempt to get Data via 433MHz from an ATtiny85. I can see the data being transmitted on the scope attached to the receiver side. There is a lot of noise before and after the data, most probably created by auto gain control in the receiver module.

Unfortunately, I never get a receiveComplete() as true for some unknown reason:

#include <Manchester.h>

#define ALERT 13
#define DATA_433 4

uint16_t packet;
uint16_t last_packet;

void setup() {
  pinMode(ALERT, OUTPUT);
  digitalWrite(ALERT, LOW);
  man.setupReceive(DATA_433, MAN_1200);
  man.beginReceiveArray(2, (uint8_t *)&packet);
  last_packet = 0x2f3a;
  Serial.begin(9600);
  Serial.println("");
}

void loop() {
  Serial.println(packet, HEX); // #1 - see below
  if (man.receiveComplete()) 
  {
    Serial.println(packet, HEX); // #2 - see below
    if(packet!=last_packet)
    {
      if(packet&0x4000) digitalWrite(ALERT, HIGH);
      last_packet = packet;
    }
    man.beginReceiveArray(2, (uint8_t *)&packet);
  }
}

The first Serial.println() (marked #1) in the loop bravely prints out the received packet, whereas #2 never prints anything at all. So it looks like receiveComplete() never is true.

What am I missing here?

Receiver is an Arduino Nano, if that matters.

2

You haven't provided details of all the hardware involved...

3

Are you willing to change to the VirtualWire library ?

4

Uh, I thought that would not matter at all, as I seem to have a software issue here. But anyway:

The receiver is a RXB6 V2.0 type (like this), read out by an Arduino Nano (as written before). I have an air core antenna attached to it (as described here).

On the sender side, the ATtiny85 is driving a cheap Chinese sender (like the one described here).

The Manchester library is mchr3k's on Github.

What else would you need to know?

5

Koepel:
Are you willing to change to the VirtualWire library ?

Not easily, as VW seems to have issues with the ATtiny85.

6

Can you upgrade the ATtiny as well ? to an official Arduino board ?

My best suggestion is to use the examples that come with the library. Set the datarate at 2400. About 2000 baud is the best frequency for those cheap modules.

Can you change the loop() function to this:

void loop() 
{
  if (man.receiveComplete()) 
  {
    Serial.println("Received something !");
    ...

You have this line running at every loop() iteration:

Serial.println(packet, HEX); // #1 - see below

That will fill the TX buffer of the Serial library, and that could make the sketch 100 times slower. It could be 1000 times, I don't know, but your sketch will almost not run.

Those modules need a piece of wire as antenna. About 16 cm wire, but any wire is better than no wire at all.

7

Koepel:
Can you upgrade the ATtiny as well ? to an official Arduino board ?

No, I am afraid not. It is in a lowest power sensor module by design.

Koepel:
My best suggestion is to use the examples that come with the library. Set the datarate at 2400. About 2000 baud is the best frequency for those cheap modules.

Will doubling the speed increase quality? Can you elaborate a bit on this?

Koepel:
Can you change the loop() function to this:

...

I had exactly that before, but never got any output of that println(). That is why I inserted the one outside the if() to see what was in the received packet. And in fact I found the expected data there, so determining the end of transmission seems to be failing here.

One solution I am considering is sending a "magic" pattern after the data proper and state end of transmission myself as soon as I see that trailing pattern in the buffer.

Koepel:
Those modules need a piece of wire as antenna. About 16 cm wire, but any wire is better than no wire at all.

Yeah, that is why I attached the air core antenna, as described above :wink:

8

I'm out of ideas. Sorry :confused: I have not used that library.

A lower baudrate will make the length of the transmitted data longer. That means a bigger chance that electrical noise might disturb the signal. Those cheap modules might not do wel with 4000 Hz data rate, so 2000 is the best.
Some modules can do 12 kHz without problem, but at high frequences the timing of the interrupt in the Arduino might be less accurate, because also other interrupts are running.

You have to stick with the examples of that library. You have reduced the data length to only 2 bytes, that is something extra that might cause problems.

Is pin 4 known to work ?
Is there a pin 13 on the ATtiny85 ?

Measure the 5V. Is the receiver getting 5.0V ?
The output of the receiver can not make the output a good HIGH level. Sometimes I set the intput to INPUT_PULLUP to help it a little.

9

Koepel:
I'm out of ideas. Sorry :confused: I have not used that library.

No worries, thank you very much indeed. Sometimes another point of view helps finding the clue.

Koepel:
A lower baudrate will make the length of the transmitted data longer. That means a bigger chance that electrical noise might disturb the signal. Those cheap modules might not do wel with 4000 Hz data rate, so 2000 is the best.
Some modules can do 12 kHz without problem, but at high frequences the timing of the interrupt in the Arduino might be less accurate, because also other interrupts are running.

I see. The data transmission seems to be correct, though, so why should the signal always fail with the end sequence (111000b) only?

Koepel:
You have to stick with the examples of that library. You have reduced the data length to only 2 bytes, that is something extra that might cause problems.

The code is in fact very close to an example provided with the library. There is a default send/receive function pair that will transmit a uint16_t - 2 bytes as well. The array variant ends up in the very same receive routine in the library, so in my case there is no difference at all to the default case. I used the array variant to maybe add the magic code as mentioned before.

Koepel:
Is pin 4 known to work ?
Is there a pin 13 on the ATtiny85 ?

Yes, pin 4 is pretty normal for this and does work. The ATtiny85 has no pin 13 (there are only 8 on the chip :)), so one mostly would use another to drive a LED. On the Nano, 13 is the built-in LED.

Koepel:
Measure the 5V. Is the receiver getting 5.0V ?
The output of the receiver can not make the output a good HIGH level. Sometimes I set the intput to INPUT_PULLUP to help it a little.

The voltage is moving a bit between 4.99V and 5.02V, but that should not matter. The power supply can deliver up to 4A, so it will be sufficient by far for the tiny circuitry.

My scope goes only up to 20MHz, so I cannot track the raw signal. But as the receiver module seems to be able to adjust to and decode the majority of the signal, there must be a very fine detail I am missing causing this. The more, as others seem to be using the library without these issues.

10

VW seems to have issues with the ATtiny85.

No, it works fine if compiled correctly.

You will have far less trouble with VirtualWire than with the Machester library.

11

You assume that a number of things can not be the problem. But the result is that you have a problem.
I even made a "law" for that: What's wrong with BME280 - #4 by Koepel - Sensors - Arduino Forum.

The buffer in the example is 22 bytes, yours is 2 bytes. You have to make it 22 bytes. What if the library writes more than 2 bytes ?

You print the packet in the loop(). But I don't care what that prints. That Serial.println() will make the sketch no longer usable. So any data is not reliable anymore.

There are many issues: Issues · mchr3k/arduino-libs-manchester · GitHub.

Can you find tutorials of others using this library with ATtiny85. Perhaps something needs to be changed to make it work.

Try to avoid pin 13 when there is no pin 13. I don't know what happens if pin 13 is used.

I think it is possible to remove the transmitter and receiver and connect them with a wire. You could try that.

What if one ATtiny runs at a different CPU clock speed then the other ATtiny ? Do you have more ATtiny85 chips ?
Did you know that lowering the baudrate does not help with two different CPU clocks ? When the difference between the CPU clocks is 10%, then a baudrate of 9600 will also have a difference of 10% and a baudrate of 1200 will also have a difference of 10%.

Perhaps you can try another receiver. Perhaps the scope sees something else than the ATtiny.

A big power supply can have big ringing/noise/peaks/bursts. Can you try another power supply ?

Did you decouple the 5V with a 100nF capacitor from 5V to GND near the ATtiny ?

I wrote down most common things, but this is not half of what could be wrong. Is there someone you can ask to look at it at your place ?

12

Are you sending the message length in the first byte?

13

@,jremington: I will have another look at it then. Thanks for the hint.

@arduarn: no, I do not send the lenght. I was under the impression that that will only be necessary if sending variable length messages. As far as I have understood the library code the transmission will be as many bytes as one gives with the call.

@Koepel: It looks like you misunderstood what I was trying to explain. The ATtiny85 is the sender, here I was talking about the receiver, that is a Nano. There we have pin 13 of course.
But you mentioned a couple of things I will think about and modify my code to try out.
You strongly are objecting to the Serial.print() - why? The Manchester library is based on an interrupt separate from the Serial control, so why should the print() affect the function?

14

Miq1:
@arduarn: no, I do not send the lenght. I was under the impression that that will only be necessary if sending variable length messages. As far as I have understood the library code the transmission will be as many bytes as one gives with the call.

Well, I could be wrong, but it looks to me like changes made by "caoxp" some time ago have probably broken the original interface. The library expects the message length as the first byte in all cases. He also updated the examples, since the old ones were broken - probably by him.

15

The sketch below will not work very well. The sketch has no limit for the amount of bytes that is transmitted to the serial monitor. That means that the TX buffer of the Serial library will get full. Once that is full, the Serial.println() waits until there a free place in the buffer. The Arduino will spend most time waiting for that.

void setup()
{
  Serial.begin(9600);
}

void loop()
{
  Serial.println("Hello World");
  if( ...)
  {
    ...
  }
}

It depens on the length of the string and the baudrate. I did some calculations, and it is not as bad as I thought. The "Serial.println("Hello World");" will use 11 milliseconds, instead of maybe a few hundred microseconds.

I guessed I missed that the receiver is a Arduino Nano. Sorry about that :-[
So now you have to find an example of someone using a ATtiny85 as transmitter and normal Arduino board as receiver.

16

jremington:
No, it works fine if compiled correctly.

You will have far less trouble with VirtualWire than with the Machester library.

Well, tried it and failed... There seems to be an interference between VirtualWire on one hand and either millis() or the NewPing library I am using for the HC-SR04 ultrasound sensor on the other for the ATtiny85 transmitting. I could not get it working.

With the Manchester lib at least the transmitter is working okay.

17

This is not going in a good direction.

Could you use normal Arduino boards and for exampe the nRF24L01+ ?

The VirtualWire library encodes and decodes the specific timing (the protocol) in software, it requires that the microcontroller is not doing too many other things. So does the Manchester library.
The NewPing depends heavily on timing.

When you use a transceiver, the microcontroller does not have to do that specific timing.
Wireless Buying Guide - SparkFun Electronics.

18

I got it working now with the method I mentioned before: I am sending a "magic" uint16_t after the data and check it on the receiver side.

Edited - although working, the code I provided was rubbish...

Code removed due to being wrong - please see below.
19

And for future reference, did you try pre-pending the packet length and it didn't work?

20

arduarn:
And for future reference, did you try pre-pending the packet length and it didn't work?

Correct. All that happens is: you will get the length byte first as part of the payload.

I even studied the Manchester lib code thoroughly to find if the length would be processed anywhere. No, not at all.