Frequency Hopping Spread Spectrumsee http://www.ti.com/lit/an/swra048/swra048.pdf , page 7, for the original text plus additional commentary.
Even higher output power can be used if the system employs some form of spread spectrum such as
frequency hopping or direct sequence spread spectrum. The reason such allowances are made is that
spread spectrum systems are less likely to interfere with other systems than are single frequency
transmitters. They also have the advantage in that they are often more immune to interference from other
systems. The limitations and qualifications of a spread spectrum transmitter are defined in FCC section
15.247
An application qualifies as a frequency hopping system under section 15.247 if:
· The transmitter pseudo-randomly hops between frequencies that are separated from each other by at
least the 20-dB bandwidth of the data channel, but not less than 25 kHz.
· The 20-dB bandwidth of the hopping channel is not larger than 500 kHz.
· If the 20-dB bandwidth of the hopping channel is less than 250 kHz, the system must use at least 50
hopping frequencies. The average time of occupancy at any frequency (dwell time) must not be larger
than 0.4 seconds within any 20 second period.
· If the bandwidth of the hopping channel is larger than 250 kHz, the system must use at least 25
hopping frequencies. The average time of occupancy at any frequency must not be larger than 0.4
seconds within any 10 second period.
how does the receiver lock on to the transmission sequence?
Some very sloppy math suggests around 4.3ms:
[50 x ((80us as worst case to lock next channel + (time for 2 bits at 300kbps))]
Well, if it were truly going to take that long, then I think the argument could be made for having a node book a suitably large appointment window with a secondary gateway and *transmitting* to the gateway on a pre-arranged frequency (that's picked pseudo-randomly and coordinated in advance each time).
The frequency hopping transmission and reception process starts at channel 0. The preamble and header are transmitted first on channel 0. At the beginning of each transmission the interrupt the channel counter FhssPresentChannel is incremented and the interrupt signal FhssChangeChannel is generated. The new frequency must then be programmed within the hopping period to ensure it is taken into account for the next hop, the interrupt FhssChangeChannel is then to be cleared by writing a logical ‘1’.
I thought LoRa used chipping rate that is significantly faster than a single bit, so even though the algorithm may start on channel 0 by the time any message (even the shortest ones) is transmitted it has been spread out over the entire range and hence the 'peak' at channel 0 compared to others is tiny. With the RFM69 we're talking of hopping frequencies in the order of many bytes, so if we used that algorithm that would end up with very high peaks at channel 0. According to the 915MHz rules that's not allowed.
I'm imagining that on a waterfall graph, that such a control channel would stand out as being persistently different from the other channels. i.e. From that perspective, I think it would be hard to argue that the algorithm is"pseudo-random."
Using control channels seems non sense to me for a hopping system , from a security point tof view. I think the channel hopping has to be purely time related. there's already used system to sync nodes / gateway . The question is if it's possible with moteino constraints. A 16 bits counter seems not enough. A 32 bits one could be emulated, sure, but at 1Mhz , moteino will be awaken every 65ms to manage it.I guess a Cortex M0 will be OK for this type of application :)
By the way , LORa is already spread spectrum, harder to jam. The RFM module is just lacking AES :-/
I'm not sure the WDT is accurate enough for any timing purpose like this, it's clock just isn't designed for accuracy. You may have measured some and found it to be useful, but it isn't specified to the accuracy you want so the actual variation across multiple processors over temperature and voltage may well be too great to make it useful. I'd much prefer to use a low power 10ppm watch crystal, the xmega parts like the atxmea8E5 can run those for about a microamp or so.
For all of you interested in frequency hopping maybe the openLRSng may be of some interest: https://github.com/openLRSng/openLRSng it's mainly used with different radio modules for long range rc planes/quadcopters, but the receivers look alot like moteinos 328p+rfm :)
For all of you interested in frequency hopping maybe the openLRSng may be of some interest: https://github.com/openLRSng/openLRSng it's mainly used with different radio modules for long range rc planes/quadcopters, but the receivers look alot like moteinos 328p+rfm :)but in the case of a star network , it cannot be used .
It could if the server sends a node address in each packet. The server would always send a packet and look for a response from the addressed node, the node would only send a response if it was addressed. The polling time for a node (rate at which data is sent to the server) would be equal to the number of nodes times the delay between each packet.
Mark.
I'm not sure the WDT is accurate enough for any timing purpose like this, it's clock just isn't designed for accuracy. You may have measured some and found it to be useful, but it isn't specified to the accuracy you want so the actual variation across multiple processors over temperature and voltage may well be too great to make it useful. I'd much prefer to use a low power 10ppm watch crystal, the xmega parts like the atxmea8E5 can run those for about a microamp or so.
Mark.
Edit: Maybe a Moteino based on an atxmega8E5 and a 32.768kHz crystal would be a nice thing to have.. ;-)
Nice found for PCF2129T
I really like the timestamp features on pin input . It's to bad there's no timestamping with the internal counter but time (and with 1s resolution) :-/ It could have been used for precise time sync.
So far, how close together are you able to maintain your time sync? Within Microseconds? Milliseconds?
If that works it would allow a grand unified approach: listen mode, frequency hopping, multiple bitrate coexistence all 'legit' and using the existing hardware.
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.
byte ack[1]{'#'};
byte rcv[1];
bool coNNected = false;
int x;
int channelS[20] {920250, 922750, 919000, 923500, 925000, 918000, 925500, 922500, 918500, 925250, 920000, 922000, 921000, 919500, 926000, 921500, 924000, 923000, 920500, 924500};
void loop() {
//read sensors , build data array
while (!coNNected) {
fixChannel();
}
coNNected = false;
//go to sleep
}
void fixChannel() {
monteino.Initialize();
monteino.Standby();
monteino.SendMessage(ack, 1);
monteino.Rx();
delay(100);
if (monteino.GetMessage(rcv) != '#') {
x++;
if (x > 19) {
x = 0;
}
monteino.Frequency = channelS[x];
} else {
coNNected = true;
x++;
monteino.Frequency = channelS[x];
monteino.Initialize();
monteino.Standby();
monteino.SendMessage(data, 4);
}
}