a few fundamental questions

[Bugeye60]

I'm working on my first project with Moteinos and am still pretty new to Arduino programming, so I appreciate the help!

Here's my setup:

• Two battery-powered MoteinoMEGAs that talk to one another sequentially, about 1000 feet apart (RFM69HW 915 MHz)
• One USB powered Moteino that listens to both MEGAs (RFM69HW 915 MHz)
• This setup is used only occasionally (one day out of a month?) so power savings is not a big concern.

Sequence of events:

• Mega #1:
• Broadcasts a 10 character message
• Mega #2:
• Receives broadcast, then:
• start = millis();
• transmits a single character to Mega #1 via sendWithRetry
• Receives acknowledgement
• finish = millis();
• latency = finish - start
• Mega #1
• Broadcasts a 20 character message
• Mega #2
• Broadcasts the latency value

(Note that I am using encryption.)


Question #1: 
If I cut the calculated latency value in half, is this an accurate measure of the time it takes the message to get from Mega #2 to Mega #1 (including processing time in the loop)?  I get a whole (not halved) latency value of 9 ms while testing on my desktop.

Question set #2:
Based on some of the questions and answers I've read in the forum, can I reduce latency by increasing transmission rate?  If so, how do I increase the transmission rate?

Question set #3:
I'm using the simple wire antenna that comes with the Moteinos and have difficulty with the 1000 foot range, in the open with a clear line of sight.  I'm using Auto Transmission Control as follows:
Mega #1:  #define ENABLE_ATC
Mega #2:  #define ENABLE_ATC plus radio.enableAutoPower(-70); in the setup.
Should I really be using ATC in this case?
Would I get more range (and more power consumption) if I don't enable ATC?
I'm not clear on how to use ATC or how to increase transmit power while using ATC.  If I want to increase power, which direction should I go (e.g. -60 or -80)?

Question #4:
In examples I've seen both radio.RSSI and radio.readRSSI().  What's the difference?

[Felix]

Your latency includes any retries so if you're after the specific amount of time that a packet needs to transmit I would do some bench tests rather than 1000m tests - (just to find out that value). But roughly, it takes only a few ms to transmit a short packet.
An ACK is an "empty" packet (no payload), it will take a little less than a normal packet, so your halving-latency method is not exactly scientific but it will give you a very rough idea of the average time. But again, testing at 1000m is not a good idea since there could be retries especially if you see dropped packets. Just do it on the bench. If you want to be more precise just count micros() before and after send, without any ACKs etc. If you want to be scientific, hookup a logic analyzer and watch the SPI traffic and the D0 interrupt signalling TX completion (see this line for more detail).
I would not use ATC if you're trying to achieve max range. As a rule of thumb, ATC is only for situations where you're well within range and you want your radios to keep the neighborhood quiet and not "yell" at each other.
Use a dipole or yagi if you want more gain, some good threads in the forum on building such antennas - see this thread for instance.

[joelucid]

I had a need for estimating TX time also when I implemented frequency hopping: I need to keep track of gateway time on all hopping nodes. The gateway includes a timestamp in all packets, but it takes some time for the packet to arrive. I use the following function to estimate TX time of the packet:

Code: [Select]

uint16_t SX1231Driver::estimateTxTime( uint8_t len ) 
{
	if( len ) len--;
	return (((uint32_t)(( 3 /*preamble*/ + 2 /*id*/ + 1 /*len*/ + 2 /*crc*/ ) +
		    ( len / 16 + 1 ) * 16 ) /* align len because of encryption */
		 * readConst( &(profiles[ _profile ].microsPerByte ) ) ) + 500 ) / 1000;
}

This basically counts all bytes in the transmission and estimates TX time in ms. Note that this is at the driver level so the txflags, sender and target need to be included in len (3 extra bytes on top of your content). Also note that len is aligned to 16
byte blocks since that's how AES encryption works.

At least for my purposes this was a useful approximation.

Joe

[Bugeye60]

Thank you both for your help and replies.

I'll disable the ATC and test again at about the 1000 ft. distance.  If that doesn't work well, I now have three of captcha's dipoles from Osh Park and can hook them up.  Just need to get some appropriate cable.

My application is timer.  There's a radio at the starting gate and a radio at the finish gate.  Both gates use break beam sensors.  The starting gate beam starts the timer on the starting gate Mega, the finish gate radio transmits a simple signal to the start gate Mega when the finish gate's beam has been broken so that the starting gate's timer is stopped.  I'm trying to determine an accurate time (within 1 ms preferably) from start to finish but of course have to account for the time it takes for the finish gate radio to signal the start gate timer to stop (so including the retries in the latency calculation is ok I think).  Still, it sounds like my half-latency method will not provide the precision I'm looking for.  I'll take a look at Felix's link to see if I can decipher how to use it.

@joelucid, it will take me some time to decipher and understand your code since I'm not a C or C++ programmer.

Thanks again!

[joelucid]

My application is timer.  There's a radio at the starting gate and a radio at the finish gate.  Both gates use break beam sensors.  The starting gate beam starts the timer on the starting gate Mega, the finish gate radio transmits a simple signal to the start gate Mega when the finish gate's beam has been broken so that the starting gate's timer is stopped.  I'm trying to determine an accurate time (within 1 ms preferably) from start to finish but of course have to account for the time it takes for the finish gate radio to signal the start gate timer to stop (so including the retries in the latency calculation is ok I think).

The resonator of the Moteino might not be up to the task of measuring time over a 1000 ft distance down to the ms: it has a tolerance of +- 0.5%. One way around that is using the rfm69's crystal (see https://lowpowerlab.com/forum/general-topics/running-moteino-from-radio-crystal/). You could also use an external RTC or replace the resonator with a clock XTAL for keeping time and run from the internal RC oscillator.

Then before you measure you synchronize your clocks using your half-latency method. However don't use sendWithAck() because of the retransmit issue. Also don't use send() because canSend() can cause a delay waiting for carrier clear. Instead use sendFrame() which sends directly. After A sends a sync request to B, go into a receiveDone() loop. When you receive the packet on B don't ack but use sendFrame() to send a packet of identical size back. This packet should include the time as measured on B. When A receives this packet it can deduce the time offset of B to A using the half-latency method. If nothing comes back (packet lost), just reattempt the sync after a timeout.

Now A measures start time, B measures end time and transmits to A. A can calculate total time using the time offset calculated during sync.

Joe

[perky]

You might be interested in this. It's a way to synchronize clocks between nodes, but the beauty is that the accuracy is independent of processing time (i.e. how long the reply actually takes to come back). Once you've synchronized the two nodes just sending a timestamp should be sufficient to detemine your stop time:

https://lowpowerlab.com/forum/moteino/moteinos-ds3234-rtc-sharing-spi-require-hard-reset-each-time/msg13009/#msg13009

Mark.

[Bugeye60]

Very interesting stuff.  I'll investigate using another clock and using the other send and receive commands (that I wasn't aware of).  I searched the net for time synchronization in wireless networks and also found lots of interesting information that hopefully I can make use of.  Here's an example:  http://www.cs.wustl.edu/~jain/cse574-06/ftp/time_sync/index.html