Author
Topic: Frequency Hopping (Read 16491 times)

I don't think you'll find an ultra low power 1mhz oscillator. There's a reason rtcs run at slow clock speeds. The am1805 gives you a 1/100th s resolution time. Plus it has a 4096hz countdown timer which you can use in combination with the regular clock to create a 250us resolution timer. That's plenty for frequency hopping. At 55nA.

BTW, I think a tcxo is overkill. I actually looked a bit yesterday because I'm planning to put a temp sensor on the GW for temp compensation of the radio crystal. So I thought if I can find a cheap tcxo that would allow me to read the temperature out, that might be a better use of board space than a separate temp sensor.

But all tcxo rtc's I could find either couldn't read out the temp or were too big or too expensive or all 3 of these ...

I think since you're syncing with a server anyway and have an (albeit uncalibrated) temp sensor on the radio you should just use a regular RTC and build up a temp compensation table in EEPROM at runtime. Cheaper, smaller, more accurate, better.

That's a good idea. but it trades something that's already been fully characterized for something with lower specs. Either way, it looks like it will be challenging to get and maintain a tight time sync. The PCF2129T gives me a little extra confidence that if it works well at the test condition temperatures, it will work well at the other temperatures too. You're right, though, that by itself may not be enough to fully justify it.

If anything, I'm concerned it may be underkill and that with or without it I may have to settle for a somewhat loosey-goosey time sync, not a spot-on time sync like I was hoping for. So far, how close together are you able to maintain your time sync? Within Microseconds? Milliseconds?

So far, how close together are you able to maintain your time sync? Within Microseconds? Milliseconds?

With the am1815 within a 1ms with a sync packet about every 10 minutes. That's without temp compensation, just frequently recalibrating the RTC.

But frankly I'd like something that works with stock moteinos. Or simple 328p + rfm69 module boards.

I've been testing the rc oscillator of the radio as timing source. It's more stable than the wdt. At the same temperature readings 5 minutes apart come out within 6ms. It does vary quite a bit with temperature and I'm sure vcc as well. There's also the challenge that it is auto calibrated by the radio on startup. That calibration is bad enough not to be useful, but hurts if you want to do your own.

But if you could compensate for current temperature, then adjust for any calibration the radio might have done on startup, I think it's not completely unreasonable to hope you can keep all nodes within 10ms of the gateway at 5 min syncs. It would require using listen mode as timer unless one wants to mod the moteino. You would sync more frequently initially when building up your calibration tables.

If that works it would allow a grand unified approach: listen mode, frequency hopping, multiple bitrate coexistence all 'legit' and using the existing hardware. Supported by a super low noise wifi gw that might double your current range (or halve your energy expenditure). Managed by an extension of ATC that tunes not only transfer power, but also choses the best bitrate/tx power available for a node.

If that works it would allow a grand unified approach: listen mode, frequency hopping, multiple bitrate coexistence all 'legit' and using the existing hardware.

It wasn't that easy since listen mode only has a resolution of 4.2ms at the > 1s range. With that granularity any clock differences quickly add up to intolerably large amounts of time. But I think I've figured out a scheme to make all of this work with stock Moteinos:

The key is not to calibrate the clients to the server, but the server to the clients: When a listen mode client joins the network it sends two requests to the gw (hopping appropriately via control channel), separated by one well defined listen mode period (say 10s). The server measures that interval using its crystal and can derive when the client will listen in the future.

When the server wants to send something it no longer needs to blast a burst for 3s. It will know with some accuracy (100ms at worst I would think) when the client will come online and can then deliver the packet using a 100ms burst. The client acks back together with any payload it might have for the server, plus frequency band and bitrate settings it will be listening at in the future (giving the client control over frequency hopping as well as bitrate optimization).

Gw acks the client ack. If received the client goes back into listen mode. Otherwise it reestablishes the connection as in the beginning. If the client notices a large temperature shift or if it doesn't receive a regular heartbeat (say every 5 minutes) from the gw it also reestablishes the connection.

AC powered clients use a less complicated version of the same scheme, telling the server at which frequency and with what bitrate they're listening and reestablishing via control channel if the connection is lost. They will be in rx at all times and can do without the listen mode synchronization. The gw will poll them regularly nonetheless to allow all communication to occur at the optimal bitrate. If they spontaneously want to send to the gw they will need to go via the control channel.

In addition to being legit via frequency hopping and saving power/air time by using adaptive bitrates this scheme has another huge advantage: it allows the use of client optimized listen periods. So if you need 300ms latency for some client and can afford the battery hit you can just configure that client for a 300ms listen period. Or if you want your listen period to be 1 minute that is now also possible: it no longer requires a 1 minute burst to wake that client.

I think this will work fine as long as the control channel isn't too slow. E.g. I could see the control channel running at 19200 baud. If you want to go down to 1200 baud for extreme range I think it would be best to just add a second gateway since you don't want to burden esp coin cell nodes with long duration control packets - even if it's only while establishing a connection.

I think this will work fine as long as the control channel isn't too slow. E.g. I could see the control channel running at 19200 baud. If you want to go down to 1200 baud for extreme range I think it would be best to just add a second gateway since you don't want to burden esp coin cell nodes with long duration control packets - even if it's only while establishing a connection.

Ha! New idea: if you have an AC powered node that does not need frequent communication (the garage controller comes to mind) you can run that at 1200 baud and use it to relay any packets from 1200 baud clients to the server at the control channel.

Only requirement is you have to add a thermometer for temp frequency compensation. The gateway will have a thermometer on board - so maybe it's still best to just add a second gateway.