Very strange bugs. 2.3. RFM69.

[mickecarlsson]

I don't know if it affecting your case, but according to the source code for the BH1750 library you need to set the mode:
Source code for bh1750 library
Note that the begin() function needs a mode parameter, and that is used in configure, it if is not provided it is an invalid mode,

void BH1750::begin(uint8_t mode) {

  Wire.begin();
  //write8(mode);
  configure(mode);
}


void BH1750::configure(uint8_t mode) {

    switch (mode) {
        case BH1750_CONTINUOUS_HIGH_RES_MODE:
        case BH1750_CONTINUOUS_HIGH_RES_MODE_2:
        case BH1750_CONTINUOUS_LOW_RES_MODE:
        case BH1750_ONE_TIME_HIGH_RES_MODE:
        case BH1750_ONE_TIME_HIGH_RES_MODE_2:
        case BH1750_ONE_TIME_LOW_RES_MODE:
            // apply a valid mode change
            write8(mode);
            _delay_ms(10);
            break;
        default:
            // Invalid measurement mode
            #if BH1750_DEBUG == 1
            Serial.println("Invalid measurement mode");
            #endif
            break;
    }
}```

[yury]

@mickecarlsson said in Very strange bugs. 2.3. RFM69.:

Note that the begin() function needs a mode parameter, and that is used in configure

Should be this one lightMeter.begin(BH1750::ONE_TIME_LOW_RES_MODE); but Koresh was asking radio related question...

[alexsh1]

@yury @Koresh I am not sure it is radio related question. However, something is not letting the node to transfer messages if delay is less than 100ms.

@Koresh Can you try to do a simple node sending say 5 messages to the GW within 5ms?
I am trying to understand if this is your code or something is wrong elsewhere. In 2.2.0 no issues?

@tekka any ideas please?

[scalz]

Hello.

Like I said in this other thread https://forum.mysensors.org/post/91188 ,
we heard you, and we will try to fix issue if there is one in 2.3 as soon as we get time (can't tell you about 2.3, I'm using customized code atm).

Regarding sketch, yes it's always easier for debugging to use a sketch with no external lib. A simple counter sender for example (often using it for this purpose), etc.

So in the meantime, you can wait and use 2.2 if you don't need something special in 2.3, or feel free to fix this issue ;)

[yury]

@alexsh1
I was trying the same code on bare RFM69 board without any external libs,
just mysesnsors2.0 and 2.2 and 2.3 old drivers. 2.0 need 30ms waits 2.2-2.3 - up to 100ms for stable ACK's and sends

@scalz
NRF24 works fine without waits.... may be you know some direction where to dig in RFM driver for gold?

[bakcsa]

@yury I've never used Mysensors but looking at the latest RFM69 driver it's clear that it waits minimum MY_RFM69_CSMA_TIMEOUT_MS (default 500ms) before sending a frame.
https://github.com/mysensors/MySensors/blob/master/drivers/RFM69/new/RFM69_new.cpp line 378

I suppose it does it to respect the regulations.

[Koresh]

@bakcsa Excuse me... Do you understand what CSMA means? :) The air in all tests was absolutely avaliable. So we have a bugs in ideal conditions (dot to dot connection without cramps).

[Koresh]

Yury and I have been digging deep into the new RFM69 driver and MySensors 2.3 for the past two days. I think it needs a lot of work so far. But good results have already been achieved :smile:
Now I can send lots of messages which requested ACK one by one without any wait between them (we tested 200 messages) and not a single NACK has ever appeared.
Will share results soon.

[mfalkvidd]

That fantastic news @koresh, great work!

[Koresh]

I've written a small article https://forum.mysensors.org/topic/9484/mysensors-2-3-and-rfm69-new-driver-problems-and-solutions