@pepson
I extracted a part of your sketch above. change the last line of the extract

@pepson
no idea if it will help you, but what i meant is sending less msg .
I think i recognize some parts of this sketch, not sure

So, in your sketch, here you can see it sends at each %

  if (isMoving) 
  {
    unsigned long _now = millis();
    if (_now - lastLevelTime >= timeOneLevel * 1000) {
      if (directionUpDown == DIRECTION_UP) {
        currentShutterLevel += 1;
      } else {
        currentShutterLevel -= 1;
      }
      currentShutterLevel = constrain(currentShutterLevel, 0, 100);
      #ifdef MY_DEBUG
      Serial.println(String(requestedShutterLevel));
      Serial.println(String(currentShutterLevel));
      #endif
      lastLevelTime = millis();
      send(msgPercentage.set(currentShutterLevel));

try to change this last line, by:

if (currentShutterLevel % 5 == 0) send(msgPercentage.set(currentShutterLevel)); // change 5 by 10 if you want to send each 10% for example

no worry about shutter level update in controller, because when it will stop it will send its level (with sendstate in shutterhalt).
As your settings in top of sketch is 20sec for a complete roll, then it should send each second instead of 200ms previously (except if you did some calibration), and if i'm not wrong, I quickly read it!

@pepson
just to know, when you get this issue, do you send to one shutter only? (because i see you're sending each %, each 200ms). Well we have already did a stress test in the past, one packet/100ms with a dozen of nodes and it worked but that was with local work, and not with rpi as gw.
I don't remember if buffer has been implemented in regular branch, for rfm69 (but I think so). And it should work like you said it works with 2.2
We'll be able retry some stress tests, unfortunately not on rpi as gw (not using this setup), I'm not sure but maybe only marceloaqno may be using rpi with rfm69. Not sure. Let us check if it's a general problem or rpi as gw only.
Sorry for disturbance

@pepson said in RFM69 new driver delay:

My opinion is that in version 2.3.0 something not working correct with radio RFM69HW.
Maybe for sensors which send data from time to time is ok , but for cover which transfer data when cover is roll, it is problem... and gateway can not recived all data when node send position cover. Maybe developer read this thread and can do any changes to correct it.

Like I said, we will take a look as soon as we get time. For the moment, busy (at least on my side). And we're a few, using rfm69.
So if 2.2 fixes your issue, it can be a good idea.

@berkseo
my comments were not about pulse power, but about rf radiation, gnd counterpoise size regarding monopole (on batt, less gnd = less range & possible freq detuning), meandered antenna prone to detuning.. (and on pic looks like you have a route behind it).
In some usecase (more range needed, or when board is enclosed etc), these details, combined, could create retransmission for example and more power used etc.
Well, I bet you could get better range if you tested different design vs range. But, no matter, great if it's working well enough for you. That's most important point
Keep the good work!

@pepson
My comments about tuning antenna were general, it can be useful for optimizing your network.

I already read what you said previously It should be normal that new&old driver not working together (unless a recent change..).

We'll take a look at which changes are incorrect. I'm using experimental local mysensors version, so I'm a bit off topic regarding official release and no time for debugging, for the moment, as like I said we'll try to check that asap.

Regarding RPI, I'm not using it as gw (I prefer a lower power gw that i can place where i want) so I'm not sure. Take it with a pinch of salt but if i remember, old rfm69 driver spi functions etc are not adapted to linux (whereas new driver is)

If 2.3 is blocking, do you need a particular fix in 2.3 ? Else you could stick to 2.2

Hi.

looks cute board. But for better message delivery reliability and range, you could improve antenna placement (for better rf radiation there should not be any routes, metal etc under antenna) + more gnd plane, else you'll get shorter range than you should expect.

@pepson @mickecarlsson
in theory, if I remember well, length of antenna should be:

• 86mm for 868mhz
• 82mm for 915Mhz
  Better check which frequency you can use where you live.

Also this is in ideal world, it depends on:

• antenna material
• gnd plane size
• etc

So when you want to tune your network, you could use a good, 868mhz for example, antenna on gateway (from a reliable supplier, as there are also a lot of unmatched antenna around).
Then you can try to tune emprically, by checking rssi vs length. Add length or cut, and check. If you need more or less length is dependant on above factors.

As already said, we don't recommand mixing new driver with older.. As packet has not the same format.
No eta for fixing rfm69 if issues, too busy for the moment, but we'll try asap.

@user2684
well, here i prefer to use a faster processing gateway. no issue with slower nodes.. but i'm not using official mys branches (could be that, not sure..).

nice to hear it's working as you wish, the most important

@firstof9 said in New RFM69 driver error:

@scalz
I've updated my sketch to include that for the new driver. Thank you.
I had to use that mod for the older driver.

Why did you say this 4months ago? Does it mean you got it working with new driver at a moment?
Then 3months later, you said you got hw sanity check error. What has changed?
Maybe, have you updated lib and get again your initial problem??

On other side, (if i get things right), nightbodom has no more sanity chech error but range issue now..

Inconsistent details with hard to follow debug , unfortunately no time actually. I'll take a look later.