Structures, Serialisation, XOR Checksums etc.

@zeferby

Indeed, templates do work, at the basic level that I have actually tested, though I am not an advanced user of them... nevertheless, enough to be dangerous 🙂  I wrote a very basic pair template class as a test... I'll see if I can dig it up if anyone interested.

I haven't tested yet, but I have seen some code employ virtual functions, which I'll have a play with soon enough too.

@robo-pi

Sorry I wasn't around to help, but glad you're problem has been solved.  Been extremely busy in my new job, and hope it settles down soon so I can have a bit more time for my own hobbies, this being one of them 🙂

Cheers!

@frogandtoad

This is certainly one of the most enjoyable threads that I have been involved with! ? 

@pugwash

Just a quick observation before I go to bed... it always bothers me when I see iteration starting at index position 1, and then a -1 is introduced, for example in your code I see:

int result = buffer[0];
  for(int i=1; i<sizeof(myObject) - 1; i++){
    result ^= buffer[i];
   } 

...where as I would prefer to see:

int result(0);
  for(int i = 0; i < sizeof(myObject); i++){
    result ^= buffer[i];
   }

Likewise, in the following function, you do not use the boolean return value to check for success or failure, but you don't need it anyway if you modify the function slightly as in from:

void sendMyData(int outgoingData){
  RF24NetworkHeader header(node01); // (Address where the data is going)
  bool ok = network.write(header, &outgoingData, sizeof(outgoingData)); // Send the data  
 }

...to this:

bool sendMyData(int outgoingData) {
  RF24NetworkHeader header(node01);
  
  return network.write(header, &outgoingData, sizeof(outgoingData)); 
 }

...then in your code you can check the function return value for success or failure. Checksum is good for the actual data, but you also want to check overall transmission too, if you really want to make it somewhat bullet proof 😉 Cheers!

@frogandtoad

This didn't work:

int result(0);
  for(int i = 0; i < sizeof(myObject); i++){
    result ^= buffer[i];
   }

but this does:

int result(0);
  for(int i = 0; i < sizeof(myObject) - 1; i++){
    result ^= buffer[i];
   }

The reason being, the last value in the array is not part of the checksum calculation. The sizeof(myObject) equals 17 but I only need the first 16 values. myObject[16] contains the transmitted checksum.

Posted by: @pugwash

If you want too!

Get some sleep!

That's what I did as soon as I  discovered the problem. ? 

This has been driving me nuts and I was actually starting to get quite frustrated and even angry that this was taking so long to solve with no success.

I was looking at the converted Fahrenheit temperatures on the serial monitor and LED display and wondering why I wasn't getting those numbers.   Believing that I had already taken care of the conversion I figured it had to be one of 4 things:

• A  type casting problem
• A radio transmission problem (i.e. losing bits during the radio  communication)
• A problem  reassembling the struct at the receiver end
• A possible problem with the RH_ASK.h library function using uint8_ t data.

So I've been focusing on all four of those possibilities and not even thinking about the C to F conversion since I was convinced that this had already been taken care of.

This isn't the first time I've done this sort of thing.  In fact, secret be known, this is basically my life's story. ? 

I'm the kind of guy who starts taking things apart to figure out why they won't run when the original problem is that I simply never plugged it into an electrical receptacle in the first place.   Or tear a whole lawnmower apart when it was just out of gas. ? 

Yep, that's me.  Never check the simple stuff, always dive into a more complicated analysis!

By the way, I just received an order of 10 NRF24L01 modules today.   So now I can try those out as well. 

This same program should work with just changing the radio library and a few radio commands.

I have now attached a Si1145 UV Sensor to the I2C bus of the balcony sensor. The sketches below have been tested for about six hours. The notable change is the number of checksum errors being received from the balcony sensor. I think there may be some interference on the nrf24l01 caused by the UV sensor.

Here is the output on the serial monitor:

Here are the latest files:

Have fun with these sketches! ? 

Posted by: @robo-pi

By the way, I just received an order of 10 NRF24L01 modules today.   So now I can try those out as well. 

This same program should work with just changing the radio library and a few radio commands.

Let me know how the nrf204l01 performance compares to the 433MHz module!

Posted by: @pugwash

Let me know how the nrf204l01 performance compares to the 433MHz module!

They both have their pros and cons depending on the intended use.   I haven't worked with the NRF24L01 yet. 

One of the obvious cons for the 433Mhz modules is that the transmit and receive modules are physically separate which requires more wiring, as well as a xmit/recv relay to switch back and forth between transmitting and receiving.  The 433Mhz modules are much older technology.  And basically obsolete.  The only thing that keeps them around is the simple fact that they were quite popular.

However, there are some advantages for the 433Mhz modules.  One advantage is the ease of using an external antenna.  I'll be mounting this transmitted inside of a metal box, so having the antenna external to the box will be nice.   This can probably be done with the NRF24L01 modules too.  I  guess you can just solder an antenna lead onto the PC board antenna?

I've been gleaning over my programs now that I have everything all squared away. 

I now read the sensor and do the temp conversion in one fell swoop using only the single variable of the struct.

Example:

pacSend.temp1 = tempConversion(dht_1.readTemperature());

So now I just have the struct variables throughout the entire program and I'm using floats, even though I don't need the precision.

Now that I have the code cleaned up I'm getting ready to move it over from an  UNO to an STM32 blue pill processor.   That's what I'll use in the final project.  I'm also working on moving the 433Mhz modules from a breadboard to a pc board.  This is where the NRF24L01 boards would be a lot less wiring and no need for a relay I guess.   I'll most likely end up building the project using both modules just to compare their performances.

@robo-pi A side remark :

I think if you need to transmit more values but don't need the float precision or don't want the associated CPU cost on the receiver side, and depending on the ranges of values to be transmitted, you could transmit "scaled" values : 1/10's or 1/100's of values with 16-bit integer types (signed or unsigned, depending on needs).

You would then have a fixed precision based on your scale choice.

Just a comment about the last files I uploaded.

Commenting out all references to visible and infrared light values has reduced the number of checksum errors.

I am still getting some checksum errors, but this could be RF interference or maybe the number of walls between the remote sensor and the local receiver.

@robo-pi

What I am really interested in, is the signal strength comparison!

I have an SDR with which I can tune in to the 433MHz signal, but the upper limit is 1.7GHz, not enough to receive nrf24l01 signals.

You are a bit of an opamp buff, would it be possible to connect the antenna directly to an opamp and give the signal strength a bit of a boost?

@robo-pi

If you haven't seen them before, it might be a good idea to watch these two YouTube videos before starting with the nrf24l01s.

A well invested 20 minutes!

And found this aswell:

https://www.instructables.com/id/Enhanced-NRF24L01/

Posted by: @pugwash

You are a bit of an opamp buff, would it be possible to connect the antenna directly to an opamp and give the signal strength a bit of a boost?

Technically you can boost the signal, but there are legal restrictions on that.   This is why I'm considering the possibility of getting an Amateur Radio license.   That will allow me to  increase the power output dramatically with additional signal amplification.   I don't really have a need for that kind of range at the moment, but I anticipate that I might find it useful in the future.  Although my health has been deteriorating lately so  the future is looking a bit dismal at the moment.  Hopefully,  this is a  temporary trend.  Only time will tell.