mqtt_esp8266_gateway and 1mhz node

[cimba007]

@mfalkvidd

It is indded working with 115200 .. at least my terminal is set at this rate and the node too. It even pumped it up to not waste too much time in the serial routines.

I used this sketch:

void setup() {
  Serial.begin(57600);
  pinMode(A4,OUTPUT);
  Serial.println(OSCCAL);
}

// Use hterm to repeatatly send the same message unti you cacn read it
void loop() {
  static uint8_t val = 140;
  OSCCAL=val;
  //Serial.println();
  Serial.print("Osccal= ");  
  Serial.println(OSCCAL,DEC);

  delay(500);
  //digitalWrite(A4,HIGH);
  //delay(1);
  //digitalWrite(A4,LOW);
  //delay(100);
  while(Serial.available())
    Serial.write(Serial.read());
  val++;
  if(val > 200)
    val = 140;
}

It just tries out various settings for OSCCAL .. thus ramping the atmega328 up and speed. There are some settings where I can receive clear messages like in the range from 140 to 160 .. so ist just set OSCCAL to 150.

This might be specific for my current serial-usb converter but for now its fine.

[cimba007]

@mfalkvidd

I might have been wrong regarding the timing.

My latest test indicates gateway sends pong at:

573.8

Node starts listeing at

572.8

Still there is not too much time ...

To be extra sure I popped an delay on the gateway side:

	Serial.println(message.type == I_PONG ? "I_PONG" : "OTHER");
	delay(2);
	//Serial.println("")
	bool ok = transportSendWrite(route, message);

Now my node is working again .. I would say the whole issue is an race condition resulting from the great difference in speed.

I found a workaround that is acceptable (for me at least):

In MyTransport.cpp I added an delay(2).
I_PING messages should not be too common to have an impact on battery life and the node now has enough time to switch to receiving mode.

				// general
				if (type == I_PING) {
					delay(2);
					//Serial.print("WE GOT SOME PING?!");
					//Serial.println(sender);
					debug(PSTR("TSP:MSG:PINGED (ID=%d, hops=%d)\n"), sender, _msg.getByte());
					transportRouteMessage(build(_msgTmp, _nc.nodeId, sender, NODE_SENSOR_ID, C_INTERNAL, I_PONG, false).set((uint8_t)0x01));
					return; // no further processing required
				}

https://github.com/mysensors/MySensors/issues/578

[tekka]

@cimba007 That's an interesting finding, I'll look into that.

[cimba007]

@tekka
I just realized that this might affect all request-response operations and a solution might be difficult to find without affecting all users that don't use this particular setup.

It would be ideal if an potential fix could be made so it would only affect the esp8266_mqtt code .. but again .. this might have further implications.

[tekka]

@cimba007 Yes - and now thinking of the upcoming RPI GW port running at 1.2GHz ... :) I think a delay of ~300ms should be safe.

[cimba007]

@tekka

Update: https://github.com/mysensors/MySensors/issues/578#issuecomment-244421537

Have a look at the timing diagram ;-)

[scalz]

Lol I don't think/hope that the 1.2ghz will break the 8mhz node :)

@cimba007 I already noticed this behaviour as I use 1Mhz nodes. but didn't digged too much because for me this was a racing issue and was making sense, especially when serial debug was enabled. But even if not, 1mhz detunes timers etc so 1ms is not anymore.
Finally, for my network stability, I have decided to use 8Mhz when radio is active. Because imho it was making more sense, that for all nodes 1ms=1ms. So, if i don't need radio, i use 1mhz, else 8mhz. So I always have a decent speed process for the communication. And when radio is active, the 1mhz power savings of atmel is too small regarding radio power consumption..

I think there is no problem to go as low as 1.8v with 328p

Also interesting about 250 000kbps baudrate, 0% error...

(I have only tried this for 4mhz, i'm not sure if it could work for 1mhz, from the datasheet it shouldn't. And that wasn't with Arduino Serial Monitor (250k).

[cimba007]

With 1Mhz I could get working was 115200.

I would like to switch to 8mhz but I have a dilemma.

I got ten 2xAA battery holders which would give me (with batteries) a working range from ~2.00V - 3.00V (approx).

The only option left is trying out the whole stuff with 16mhz / 8 = 2mhz but .. well .. I can't reflash the fuses on the jnode after assembly.

The other option I have is to switch to LDO + LiPo battery but I was not too sure to put lipo batteries all over my place for safety concerns. Don't know what will happen if on a hot summer day the lipo might get a full day of sun radiation when placed near a window for example.

[cimba007]

Update: I missed one important point .. OSCCAL doesn't range from 140 to 200 but actually from 0 to 255

I changed the ranges and ...

void setup() {
  Serial.begin(250000);
  Serial.println(OSCCAL);
}

// Use hterm to repeatatly send the same message unti you cacn read it
void loop() {
  static uint8_t val = 0;
  OSCCAL=val;
  //Serial.println();
  Serial.print("Osccal= ");  
  Serial.println(OSCCAL,DEC);

  delay(100);
  //while(Serial.available())
  //  Serial.write(Serial.read());
  val++;
  if(val > 250)
  {
    while(true);
  }
}

Believe it or not

Starting from osccal 239 .. which is technically 12/8 = 1,5mhz and not 1mhz .. I was able to receive some data .. with the drawback that all delay functions etc. might be "a little bit" off.

Wohoo .. 1,5mhz @ 250.000baud

Might be some artifact but .. it is still nice to know ^^

[cimba007]

Somehow the graph from the datasheet doesn't fit at all for my internal oscillator.

Just an example .. I programmed the fuse to output the clock on PortB0 and I got:

OSCCAL=66;
Serial.begin(57600);
~973 KHz

OSCCAL=66;
Serial.begin(115200);
~973 KHz

OSCCAL=240;
Serial.begin(250000);
~1.88 MHz

I would expect OSCCAL = 66 to get me ~ 6/8 = 800KHz

[cimba007]

Using Serial.begin(115200) I experienced some lockups of the atmega328p .. serial communication stopped completely as well as all other operation .. WTF ?!