Posts made by GaryStofer

First let me say that the test "network" consists of a single node and a Serial GW with a Domoticz controller only. No repeater nodes are present and it operates at 250Kbd on a frequency outside of the WiFi spectrum verified to have no traffic. The test subjects are within 10 feet of each other and the protocol sniffer receiver is placed roughly midway between the two communicating nodes. The test node has a plugable connector for the RF modules so that I can switch them out separately. The GW has the LNA/PA module and the node is using the standard mudules. Both GW and node are set to "High" power.

Looking at the problem with the promiscuous protocol sniffer and wireshark I can clearly see that packets collide mid air when both the node and the GW transmitting at the same time. This happens when the controller/GW talks to the node while having the protocol ACK request enabled and the node does not have the extra wait/delay programmed.

Going through 12 RF modules node side, I can see that about 1/3 shows the problem consistently to the extent that all 16 retransmissions are used up , 1/3 to various degrees and the rest shows no problems at all. Before you say "ohh fake chips etc." these modules all came from the same batch, so more than likely not fake and non fake, but rather some parameter that the lib assumes to tight of a margin for.

When turning off the protocol level ACK via the controller/GW, the package goes out without an request for the node to send back the package, only the HW ack remains in the picture. Setup like this I can see that the third of the modules that cause the persistent collisions evoke a re-send of the package by the GW after ~2 to 2.5ms , while the group that shows no problem shows one single transmission from the GW only. Since the sniffer is not fast enough to capture the quick turn around ( spec says 130us) for the short HW ack to go out I can not get say whether the node is simply not sending it or just not sending it in quick enough. All I can say is that the GW code did not see a HW ack and therefore sends out the package a second time.

Meanwhile on the node side all is well, it just might get the same package twice and since no status changed there is no harm done. However when you now turn on the protocol level ACK request in the controller ( as you should) the node has to turn around and send out the echo package which then collides with the resend of the original package from the GW. The node also doesn't get an HW-ACK becasue of this and tries to resend the echo package over again until it runs out of tries.

When I then introduce the wait/delay in the code above to wait out the 2.5Ms for the GW to resend the initial package this ACK/resend storm goes away because the air is clear when the node sends it's echo package. If I wait/delay for 2 ms the problem is greatly reduced and if I wait 3 ms I see no more evidence of collisions. Either wait or delay works however, I choose delay() to be positively sure that no other communication is started during that time by the node.

I conclude that as a work around this solves the issue we are having with the RF24 transport, but without further investing into faster RF sniffing equipment I can't say for sure if this could be solved better on the TX side by waiting longer for the HW ack to arrive from the receiving node, however I think there would be a good chance for that.

There is also a chance that the PA/LNA module used on the GW could be part of the problem by not being able to switch quickly enough back to RX mode and therefore loose the HW-ACK for nodes that respond quicker than others.

Edited: Checked with a non PA/LNA module on the GW and no change could be observed, so this theory can be discounted.

BTW: All of this is very reminiscent of an email communication in 2015 I had with Ekblad !!

GS

@skywatch yes, wait() works too. My thinking for using delay() was that I did not want any possibility of any incoming message being processes during that time, so therefore delay instead of wait. But I did not do any further digging in the code to assess such risk or do any stress testing with the node being a repeater also , etc. I figure the implementers of the lib would know what's best when implementing a fix. It's also possible that the root cause lies in the Serial GW code if other gateways do not have this problem. It could be that it just takes the GW code a little too long to switch into RX mode to catch the ACK. I figured @hek or @Yveaux would get to the bottom of it and know what to do. Do they still read the forums or do I need to do a pull request on the GIT ?

GS

When communicating from the gateway to a node there seems to be none, or an insufficient delay for the TX/RX turnaround time. This causes the GW not to fully receive the incoming ACK message and therefore fail the transmission. With a protocol sniffer it can be observed that the receiving node sent out the ACK message immediately , but otherwise properly.

The mere inclusion of MY_DEBUG serial print messages on the receiving node, "solves" the issue by
providing a slight delay between reception and subsequent transmission of the ACK/ECHO package allowing the transmitting node to switch from transmission to reception properly.

A delay of 3-4 ms in file MyTransport.cpp / line 703 in the code block of

if ( msg.getRequestEcho()) {
     TRANSPORT_DEBUG(PSTR("TSF:MSG:ECGO REQ\n")
#ifdef MY_RADIO_RF24
     delay(4);
#endif
....
...
..
}

Solves the issue of the lost ack messages.

This has been tested on multiple RF24 modules -- With and without LNA/PA both on the gateway and node sides.

Suggest to add above code to the code base so that other people don't have to go through days of debugging to find this problem again.

See post further down for details and explanation .

G.S.

@mfalkvidd No, the issue with sleep(0) still exists in V2.3.2. That is the version that the ArDuino Library installer installs currently . -- Work around is to call hwPowerDown(WDTO_SLEEP_FOEREVER) as in above code if you want the battery to last more than a day.

GS

Solved by adding a short delay between the RX/TX turnaround when replying with an ACK message.

In file MyTransport.cpp at line 706 in the "if (msg.getRequestEcho) block, right after the debug message "TSF:MSG:"ECHO REQ" added a 2ms delay to allow the caller to switch from TX to RX mode.

GS

@ferro , @monte, @hek , @Yveaux
I guess I have not mentioned this before :
When turning on MY_DEBUG or MY_DEBUG_VERBOSE_RF the ACK problem goes away . The Debug trace looks as expected and the GW is happy with what it gets back from the node in terms of ACK. No error message .... turn Debug off and the problem reappears.

This is why I think that there is a timing issue, with the RX/TX change over time. By adding the Serial prints it slows the RX/TX change over down enough for the GW to be able to catch the ACK package and be happy.

If Hek or Yveaux is not going to put his hat in the ring here I guess I have to either run with debug permanently on -- Heck a messy -- or dive down and debug the library myself.

GS

@ferro The systems use the Serial Mysensor GW -- some connect via USB some connect directly to the serial port on a Pi.

I cant change the Controller to anything else , not that I think is controller related -- The customer is happy with Domo and has many man hours invested in scripts and interfacing.

ACK, when transmitting from node to GW/controller, seems to work fine, both HW-ACK and "protocol" ack. ACK from GW/Controller to node seems to be flat out broken, but I can't tell yet if the node is not sending out, or the GW is not receiving it properly.

Also noticed that the GW code is not using the IRQ line from the radio, I see the SPI clock running on the GW constantly.

Thanks

Also

@monte
Yes --- I know why it "Works" without ACK enabled -- That's not the point. But of course one needs to have the ACK working on the GW otherwise the controller and Node can get out of sync status wise.

Yes -- all of the above you mentioned was tried -- It's not a HW problem, nor a RF interference , nor a range problem -- Spectrum analyzer shows no other traffic on the chosen Freq.

Like I said -- All this worked under 1.5 reliably -- with the same HW -- Flawlessly, even on a somewhat noisy RF channel.

@ejlane No -- Not every time -- Just when I need it ---

I am working on upgrading a couple of existing Mysensor 1.5 networks to the latest version and am again running into this behavior of getting the dreaded error message: "Error sending switch command, check device/hardware !" from the Domoticz UI when trying to send commands from the controller to Relay nodes. Even just using the relay example from the lib shows the problem. I am convinced that this is not a common HW issue as often blamed. The issue has been verified with a multitude of HW and I see no other communication issues such as range etc.

So, the problem shows up on any message sent from the controller to a node. For testing purposes the network has only the Gateway and one Relay node. When clicking on the Lightbulb device to affect the relay most times, but not always, you see the error message after the timeout, even though the command was received and handled by the device right away. You also see that the controller sends the command a second time, when this happens ( about 90% of the times) .. No change in network frequency or phase of the moon makes a difference here.

Now here is what I found that did make a difference:

When I go on the Domoticz UI under "Setup/Hardware" and drill down through the Gateway "Setup" link to the Node and then select the child under scrutiny, I see at the bottom of the page an On/OFF selector labeled "ACK" together with a timeout value of 1200 . If I turn this "ACK" off then the node works flawlessly -- a million times / forth and back and even through power failures of the gateway/controller. I see only one command sent and no error messages ever.

Upon further investigation I further found that right after initial inclusion of a node this "ACK" feature seems to be off. The node works without retires/ error messages, however only until you go and update it with a name for example, then the ACK features gets turned on by default.

Now the question to @hek is : What is this "ACK" feature doing-to/expecting-from a node. Is this looking at the HW ACK from the NRF24 radio and that's what is getting missed by the GW most of the times. Is there some sort of TX/RX turn around time that is too short possibly? Or is this based on some response packet the node is expected to send from it's receive function? I did not see anything mentioned in the examples or the .h files to that effect.

When checking the HW-ACK from the Node to the GW ( in the node sketch ) I find that it works as expected. I only get NACKs when I block the antenna sufficiently to suppress the transmission.

Disabling the "ACK" feature for the node via Setup/Hardware/MyGateway/node/child on Domoticz is a workaround but probably not the desirable solution, especially as long as the problem is not fully understood.

@hek @Yveaux ??

@ejlane

yes -- EEprom gets erased by code in the before() section

@Elfnoir @hek I see this old issue is still with us in MySensor 2.3.2 / Domoticz 4.10717.

I am working on upgrading a couple of existing Mysensor 1.5 networks to the latest version and am again running into this behavior of getting the dreaded error message: "Error sending switch command, check device/hardware !" from the Domoticz UI when trying to send commands from the controller to Relay nodes. Even just using the relay example from the lib shows the problem. I am convinced that this is not a common HW issue as often blamed. The issue has been verified with a multitude of HW and I see no other communication issues such as range etc.

So, the problem shows up on any message sent from the controller to a node. For testing purposes the network has only the Gateway and one Relay node. When clicking on the Lightbulb device to affect the relay most times, but not always, you see the error message after the timeout, even though the command was received and handled by the device right away. You also see that the controller sends the command a second time, when this happens ( about 90% of the times) .. No change in network frequency or phase of the moon makes a difference here.

Now here is what I found that did make a difference:

When I go on the Domoticz UI under "Setup/Hardware" and drill down through the Gateway "Setup" link to the Node and then select the child under scrutiny, I see at the bottom of the page an On/OFF selector labeled "ACK" together with a timeout value of 1200 . If I turn this "ACK" off then the node works flawlessly -- a million times / forth and back and even through power failures of the gateway/controller. I see only one command sent and no error messages ever.

Upon further investigation I further found that right after initial inclusion of a node this "ACK" feature seems to be off. The node works without retires/ error messages, however only until you go and update it with a name for example, then the ACK features gets turned on by default.

Now the question to @hek is : What is this "ACK" feature doing-to/expecting-from a node. Is this looking at the HW ACK from the NRF24 radio and that's what is getting missed by the GW most of the times. Is there some sort of TX/RX turn around time that is too short possibly? Or is this based on some response packet the node is expected to send from it's receive function? I did not see anything mentioned in the examples or the .h files to that effect.

When checking the HW-ACK from the Node to the GW ( in the node sketch ) I find that it works as expected. I only get NACKs when I block the antenna sufficiently to suppress the transmission.

Disabling the "ACK" feature for the node via Setup/Hardware/MyGateway/node/child on Domoticz is a workaround but probably not the desirable solution, especially as long as the problem is not fully understood.

@hek @Yveaux ??

@eiten The puzzle is , why does the existing network function without fail under the same conditions, while the new network can not even connect when the nodes are a foot apart. But then if eventually they connect I get full expected range with no missing acks ..

@skywatch duh !!

I am upgrading a network that has been running for probably 7 or 8 years now to the latest version of the MySensors Libray (2.3.1). The nodes and the serial gateway are purpose built PCBs that contain a 328P, power regulators and the radio boards. The old network operated on the default ch #76 without any significant problems for years,
Now with the latest v2 Library I have the problem that the nodes fail to connect to the gateway during the power up, i.e. network init and presentation fails with NACK's. On the LEDs of the gateway I see that the communication attempts are marked with the RED error led in unison with the NACKs from the debug output of the connecting node. ---

Here comes the strange bit: If I eventually get the node to connect with the gateway by putting the node right over the gateway and waiting long enough (minutes) , I can then move the node away across the house and it communicates without a single failure all day and all night long.

At this point there is only one node and one gateway in the picture and the Node's parent is directly set to the gateway address of 0. All "user mode" communication is done with the HW-ACK feature on since we have only a single hop network. Network operates at 250kbits/s and changing power settings do not improve the issue. Nodes use IRQ signaling and I changed RF24.cpp to poll the IRQ line for transmit as well instead of polling status via SPI.

So the question is: What is different during the init and presentation that makes the nodes not connect, but then once the hooked up eventually makes the network function after all.

When switching to a channel above about 100 , i.e. out of the WiFi spectrum I get no, or almost no initial NACK failures.

So what has changed that it can't get through the initial phases of the node connect on a slightly noisy channel even when mere centimeters apart.

For people who like a clean PCB sensor or serial gateway node based on Atmel 328P for battery or 5-12V operation check out the PCB I made here on https://oshpark.com/shared_projects/5RV25Fc0. It incorporates the voltage regulators , capacitors and connector to simply plug in a NRF24 module and be done with it. Soldering is required but not terribly difficult. I usually just depopulate an Arduino nano for most of the parts ...

@alex28 Hi Alex, sorry for your frustration.

I think documentation, either incomplete or outdated, is the crux of most open source projects.

I can not speak to the Hardware you used to try to get a network up as I have stuck to the more simple approach of using the simple Arduino ( ATmel328P) nodes for both sensors, repeaters and gateways, while using a RPI as the network controller with something like Domoticz running on it. I started years ago , even before the RFM069 was an option and made PCBs that incorporate the NRF24 and the ATMEL 328P along with the necessary voltage regulators etc. Maybe it was easier to get started then because there where less options and less misleading documentation was available, but I don't recall running into any problems worthwhile of mentioning or having the level of frustrations you have encountered.

I have two sites running with 8 and 12 nodes each. All sensors running on batteries. The range of the NRF24 is limited in that I only get through one or two sheet rock walls inside the house, but using the NRF24 module with the built in PA/LNA on the gateway and one repeater opened up the range considerably. I'm fairly positive that all the NRF modules I have a re clones....

I use the serial gateway on the Atmel328p and connect that directly to the serial port of the Rpi Zero-W, without USB adapters then run Domoticz on the PI to get onto the internet .

If you look on OSH - PCB you will find many good PCBs that you can make MYsensors nodes with using the more simple Arduino platform.

Most of my frustrations stemmed from the Linux configuration for the RPI so that it doesn't clobber the SD card on surprise power failure.

Cheers -- Gary

@neverdie said in 2AAA battery NRF24 Sensor PCB with ATmega 328p:

Hmmm ... is that accurate? I thought digital LO may be higher than actual GND.

Yes, perfectly accurate. The output stage is a FET switch and the current it switches to GND is ~2 micro amps, It's 0V. One could measure the VCC an other way not needing a voltage divider by configuring the ADC so that it uses the VCC as the reference and then measure the internal 1.1V reference. However that takes re-configuring the ADC each time into and out of this mode if you need the ADC for other measurements as well and doesn't save any pins.

@neverdie
The LDO is only used when running from 5 or 12V supplies. Cant measure 3.3V with a 1.1V reference .

On this board I use a resistor voltage divider with the low end connected to a digital pin instead of ground. When a voltage reading is to be obtained the digital pin is commanded to become an output and set low, then wait for the filter capacitor to charge, take the reading and set the pin back to input. The same digital pin also has the push button switch connected which is checked elsewhere in the code, in that case the two resistors making up the voltage divider become the pull-up resistor for the switch . So the resistors and digital pin serve double duty. The internal reference of the 328p ( 1.1V ) is used as the reference for the ADC , which results in a very precise result.

Here is a MySensor node implementation on a PCB that can be ordered at OSHPARK.com. It contains a "Arduino pro - mini" chip( ATmega 328p) and has the footprint for a nrf24 radio built in as well as footprints for the necessary voltage regulators and capacitors if the node is to be run from 5V or 7-12V supplies. The Bat+/Bat- solder positions take either a 2 AAA or a 2 AA battery case. When used as a battery operated node, for example as a door/window sensor the batteries last about 2 years. The node has a built in way of measuring the battery voltage that doesn't itself deplete the battery slowly and features two LEDs driven from one digital pin.

The PCB's can be ordered at OSHPARK.com in the US , search in the shared project for "nrfMysensor. They cost around $9 per 3. Soldering is not too terribly hard. The smallest components are the two LEDs which can be left out. The arduino chip can be "harvested" from a pro/mini board, either the 8mhz/3.3V version for battery operation or the 16mhz/5V version for 5V-12V operation. Or load the appropriate bootloader onto a blank chip.

The EagleCAD board and schematic files can be found here :https://github.com/garyStofer/Eagle5_PCB/tree/master/nRF_Mysensor. The schematic contains notes on various build options.

Some example of using the boards in a battery scenario can be found here https://github.com/garyStofer/MyMySensors2.1 Wire_Trip_alarm and PIR_alarm_PCint

For battery powered nodes that need to completely sleep between events sleep(0) could be used in V1.5 in conjunction with the pin change interrupts on portC of an ATmega 328p. It would gracefully power down the radio and then enter the CPU into sleep mode until a pin change event on port C woke it up. In V2.1 sleep(0) simply returns. PortC pin-change mode is needed because INT0 and INT1 only work on either falling or raising level changes but not on either edge at the same time on the 328p .

I modified the file MyHwAVR.cpp as follows to restore the missing functionality back into V2.1 : Lines 150 and up:

int8_t hwSleep(unsigned long ms)
{


	if (ms>0) {
		// sleep for defined time
		hwInternalSleep(ms);
		return MY_WAKE_UP_BY_TIMER;
	} else {  // Fix for missing feature that allowed (in 1.5.1) to use the pin chnage interrupt with a sleep(0) to completely power down the system
		// sleep until ext interrupt triggered
		hwPowerDown(SLEEP_FOREVER);
		return 0;
	}


}

Let me know if this is the correct venue to bring this to the attention of the code maintainers, or if I should go and furnish a git pull request or something like that.

Or if this has been addressed in post V2.1.1 releases
Thanks
gary

I made a MySensor gateway node that works as a bridge to an existing X10 system. It allows to control the X10 light and appliance modules from the home automation software. The setup consists of a X10 remote which has been modified so that the digital signal from the gateway keys the transmitter. The X10 controller then receives the data package and does it's thing on the AC line to control the switches. Any existing X10 remote or alarm sensor can be used. I had an old key-fob with broken buttons that became the donor transmitter. When hacking the remote one looks for the signal from it's IC that normally keys the transmitter and disconnects that to feed the signal from the MySensor node instead. A scope is handy to find which pin is the right one.

The GIT with the Arduino script for the Gateway/X10 controller can be found at [https://github.com/garyStofer/MyMySensors2.1] . The X10 house code is hard-coded to 'A" and I limited the number of switches arbitrarily to 12, but the avid Arduino enthusiast will quickly see how to modify the code to suit. It is not necessary that the X10 part be implemented on the MySensor gateway, it could just as well be done on a separate node.

If there is any interest I will add some pictures and schematics.

@dbemowsk Initially I uses an AS5030 encoder, but then I switched to the EM-3242 as it's much cheaper and smaller and does the same. My board has an Op-amp inverter to change the sense of angle to voltage so that the magnet can run on the top of the chip rather than on the bottom. Only problem we had with the EM-3242 was that it has no hysteresis which shows up at the 360/0 junction.

I did some wind speed and direction sensor boards that I use in my own weather station design. All solid state and high resolution with analog signal readout, voltage for direction, 8 pulse per rev for speed. For inspiration see http://wws.us.to. Gary

@Yveaux So I found the problem now.

The disconnect between the sniffer and the network running V2.1 stemmed from the change in the way the NETWORK_BASE_ID is defined.

In the sniffer and V1.51 of the lib it is defined as a single uint64_t but in the V2.1 lib it is defined as a list of 5 individual bytes which are then later used to initialize a 5 byte char array via a macro.

Since earlier I had chosen a different NETWORK_BASE_ID from the default this uint64_t defined ID was now used to initialize the 5 byte array, except of course that only the first location got assigned anything. Luckily all of this happened without a compiler warning or error...

After I changed the NETWORK_BASE_ID in my nodes & gateway to use the 5 individual bytes format in the correct order everybody is all again. Even my V1.51 sensors that have not been recompiled yet seem to be just fine with the network.

Thanks

And I forgot to mention that the data rate in the sniffer and the network match as well..

Re: NRF24 Sniffer

I have been using Version 1.51 very successfully with the sniffer, but when upgrading to V2.1 I find that the (v1.51) sniffer doesn't see any traffic anymore even though the PAN-ID and RF channels match in the config files.

What has changed at the RF link layer that makes the sniffer not detect any traffic and what do I have to do to it to make it work again?
tnx

Maybe you can setup a RF sniffer as seen here http://forum.mysensors.org/topic/242/wireless-nrf24l01-sniffer-for-mysensors and observe what traffic you see when the system or node fails to give you some clues as to what is going on ?

You can do it ! Tweezers and magnifying goggles ( from Harbor Fright ) and you are in business.

Don't forget to set the Arduino to internal clock 8 mhz via fuse settings when rinning at 3V -- Most of them run without it but some might not be happy running 16mhz of the xtal at 3V .Gary

I made a little PCB that connects an Arduino ProMini i.e. see here with a nRF24L module and contains two LEDs one Switch and a voltage divider to measure the battery voltage. The board can be ordered from here OSH PCBs for about $3 for 3 PCBs, in the US at least.

Send me a message if you want the Eagle PCB files.

See schematic below -- follow notes on schematic -- Do not power with 5V serial adapter, radio will not like 5V.

There is a slight silkscreen mistake on the pcb near SV2: Mosi should read Miso.

Pro mini used :

Yes, changing the "switch type" to Motion helped a great deal. I would never have thought of a motion detector to be considered a switch. I guess it works in a backwards kind of way. I get the source on my RPi next and have fun with that and trying to figure out why the simplest of Blockly events all fail to execute with error message. Have not found much deliberate documentation on their site, such is opens source I guess ..... Seems to be snappy though.

How is your own script tying into the system?

G

@hek @AWI Ahhh beta feed! Yes, that helped. Now I need to figure out Why I get LUA / Blockly errors on all events. Something about a nil utilitidevice . Thanks !

@AWI I installed the latest BETA version and Enabled MySensor via the Serial/USB gateway. I have a simple network with one PIR Motion Sensor which sends a V_TRIPPED and a battery status message every time the motion detector goes off. I can see in the log that Domoticz communicates with the serial GW and that it gets a message every time the sensor goes of.
HOWEVER the system identified the motion sensor as "Lighting 2" and doesn't convey the status of the PIR, but rather thinks it's a light bulb. The last seen date never changes after the initial startup of the sensor , however the battery percentage seems to read correctly,

Where is the MySensor implementation coded ? Is it modifiable on the end system via scripts or is it compiled in?

G

@bjornhallberg I like to give Domoticz a try, but I can't find any mention of a MySensor plug-in anywhere in their Documentation nor on the Wiki. The only mentioning I see is on the MySensor.org controller page saying that it's supported.

How are your MySensors talking to it?

gary

@bjornhallberg I installed AGO and the Mysensor plugin on my RPI/b and after much head scratching and picking out little tidbits here and there on how to get this to load I have a MySensor sending data to it. -- The webgui is reasonably fast, but for the world I can't figure out what you actually can do with it or how you could use the GUI to configure any action to be taken depending on a Sensor reading. The Documentation is totally missing any hints as to how to use the thing.

Without any clue as to how to make this do anything useful I will format the Rpi's SD card again...

Because the file MyGateway.cpp includes utilities/PinChange.h and because MyGateway is not in it's own library a MySensor node can not make use of any Pin change interrupts.

The PinChange.h file defines the interrupt vector service routines inside the MyGateway.cpp compile unit and since all of MyGateway.obj is included in every end node you end up with a link error due to multiple defined symbols.

I suggest to either move MyGateway.cpp and it's associated example files into it's own library so that the conflict can be eliminated -- Or don't use the Pinchange but instead use the regular interrupts since the default Inclusion pin is defined as "3" which is on INT1 and doesn't use a PC_int.

Gary

So I have looked at this some more and I can see that with the following loop function in the node sketch I get an ACK response storm from the gateway. This is still in a single hop network ...

MySensor gw;
MyMessage msg( CHILD_ID_LIGHT, V_LIGHT_LEVEL);

void loop ()
{
    bool received_by1st_hop;
    msg.set(12);
   received_by1st_hop = gw.send(msg, true);   // send this with an ACK request
   /*
    for (int i =0; i <10; i++
    {
        delay(1);
        gw.process();
    }*/

 // gw.sendBatteryLevel(44,false);

   gw.sleep(3000);
}

On the air I get an initial message from the node to the GW with the ReqAck bit set, followed by 16 messages from the gateway spaced about 2 ms apart with the IsAck bit set. This is in addition to the HW ack that the radio chip on the GW already sent out.

The GW keeps sending isAck messages out, presumably because it waits for an hardware ack i.e. it waits for an ack for its isAck reply. This is highly unexpected -- One doesn't usually have to acknowledge the acknowledgement.

See the Wireshark trace below, note however that hardware aks are not captured.

The second send of the Batterylevel, if enabled, is being sent during the time the GW is busy sending isAck messages and they either collide midair (as evident in CRC errors in Wireshark, not shown above) or are otherwise not seen by the GW being busy.

If I un-comment the for loop calling delay() and process() after each send request I get the proper behavior from the GW by only sending out a single isACK message, presumably because it gets its desired hw ack.

This double ack mechanism is entirely confusing and at least should be better explained if indeed it is supposed to work this way, needing and hw ack for an IsAck mesage.

How is this working in the RF 69 implementation? I'm trying to wite an application that is going to deploy with nrf24 and/or rf69 hardware.

Cheers Gary

Thanks Hek for the quick reply.

The 3.3V power rail feeding the radio chips is rock solid at 3.3V, checked on both nodes with DSO.

The bit about mSetAck makes sense. So what does the ack argument on the send functions do ? Does it set the RequestAck (bit?) as well?

Does a true return from .send() mean that the message was acknowledge all the way, even if a router was in the path? Likewise does a false mean that the ack was not received by the sending node.

Is .send() blocking when called with request ack, or should I call sleep() or process() in between the individual .send()'s.

Using v1.4 in a simple two node configuration , End-node and Gateway a few feet apart, with the Gateway node hooked up to the very elegant MYScontroller to display and dissect the messages from the GW.

I'm having trouble to understand the function of the ACK flag on .send() and .sendBatteryLevel() as well as the affect the macro mSetACK(msg, bool) has on the thing.

My end node sends two messages each wake cycle. The first one with the battery level , the second with a measurement reading .

If I call both send messages with false for the ACK flag I get both readings on the GW as I expected and I see that the ACK flag on MYSC is indicating "NO". When I then set ACK to true on the send BatteryLevel() the second message with my measurement value is not being received anymore, except every 30th time or so, and MYSController still reports "NO" ACK for the Battery level message.

If I change the script around to send the measurement first (with ack set) then the BatteryLevel message disappears, but still with a "NO" for "ACK" on the GW.

If I call mSetAck on the msg object for the measurement then the GW shows a "YES" for ACK , but still only the first message ever makes it through.

I can not find a description for this ACK mechanism in the documentation. The API reference is mum about what the return values from .send() and .sendBatteryLevel() mean.

When I look at the return values from these calls I get a true while I'm close to the GW, but a false when I move the nodes apart a couple of yards even though the message actually still made it all the way to the GW..

How is one to use this to receive a simple true/false indicating that the message was received at the GW.
My application needs to send data for 4 child sensors plus the battery level each time the sensor wakes up. AND it needs to sound an alarm when communication is failing !

This is NOT a hardware problem --

Thanks for your help

Ahh -- Yes I recall now, same problem on the SI44xx chips.

So maybe a "bind" mode that uses a know fixed ID (maybe all F's) in conjunction with a random PAN_ID that is compiled into the gateway only. The randomness is controlled by the build process or it could be a sequenced number etc.

Bind mode on the gateway would use the known fixed ID and it would only respond to GetPan_ID requests from nodes. The mode would be entered during boot, detected by a button press or jumper. The gateway would not exit bind mode until it is rebooted with the jumper removed.

The end/router nodes would be built with the fixed ID programmed in the EEprom (hence all F's) and would therefore know that it has not gotten a PAN_ID yet. It would then enter a loop asking for a PAN_ID from the gateway, using said fixed ID . The end/router node would indicate a successful exchange of the PAN_ID by setting it's LED (on PB5/SCK ) and entering an indefinite loop after storing the PAN_ID in the eeprom.

The end/router would have an option to ease the EEPROM during the boot of the node by detecting a switch closure or jumper to force a rebind to a different network.

So from a user's point of view to bind a node you place a jumper on the gateway and the node then power both. Wait until you get a green light on the node. at which point you remove the jumpers and reset both.

When playing with the PAN ID yesterday I noticed that the lower 8 bits (I think) showed some strange behavior. Is the library using the data pipes, and therefore 7:0 is not actually usable in the PANID?

Gary

Thanks for the reply --

An other network I have been using before did this following sequence to have unique PAN-ID.

The fresh out of the box gateway creates a random number from radio noise and uses that for the long panID from that point out.

A fresh out of the box node binds to the strongest network and stores the PANid in it's eeprom. An already commissioned node can bind to a new network by booting with a button pressed on it.

It's pretty simple and works well as long as you are close to the gateway when you bind the node.

G

How is a MySensor network commissioned?

Is there a PAN id that distinguishes your network from the neighbors, and if so, how is this PAN-ID generated and disseminated to a fledgling network.

In the source I see mentioning of a PAN-ID as well as a Channel #define. But with hard codded values you would have to compile the code specifically for each network.

Also I see there is a concept of a persistent NodeID which, as far I understand, is doled out by the controller (or is it the gateway). If you bring up two new sensors at the same time, how do you know which sensor got which ID?

Do sensors have friendly names that are assigned by the end user to distinguish the bathroom from the bedroom window sensors?

Thanks -- Gary

@phil83
Why not put the pro mini circuitry on the board in the first place?