I spent a lot of time on the phone inquiring about specific laws within Australia on the subject of dwell time. Conclusively there is no specific document that covers this unlike the American FCC or Europe.
Conventional wisdom purports that a transmitter shall not continuously operate on a single channel at 30dBm.
I was under the impression that the radio must change channels at every transmit.
"Continuously" is not a broad definition to myself, how long is a piece of string ? , in context the meaning here is "A minute or less.". Note there is no definition for a receiver (receives only).
"Continuously" also applies to the period the transmitter radio is on (not transmitting).
So with a little knowledge i drew some plans, made some notes and a few calls.
I will say that any Government document can be modified at any point, therefore common sense prevails.
Back to the topic at hand ::)
My current nodes transmit an ACK, if the receiver acknowledges then both transmitter & receiver switch to the next available channel and so forth....
When a bird sits on the antenna this handshaking persists until the blighter flies away :'( or any unforeseeable interference. Code becomes lengthy and bloated.
I posted a batch file https://lowpowerlab.com/forum/projects/generate-random-channel-list-on-windows/msg15706/#msg15706 (https://lowpowerlab.com/forum/projects/generate-random-channel-list-on-windows/msg15706/#msg15706) to generate a random frequency list.
I am waiting for some DS3231 RTC to arrive.
New setup
My theory is when the transmitter awakens check which minute it is now, if it is i.e. minute 0,
select from frequency array index 0, initialize settings, send data, sleep xx minutes.
I am limiting my network to 60 transmitter nodes i can forgo using addresses, as the receiver is always ON. I endeavour to use 60 channels :P
With the RTC every device in the network is at the correct frequency at transmit & receive time.
So keeping closely inline with the FCC rules more or less, 400ms transmit in a 20sec window time frame. Padding out a 16s sleep on either side of 1 minute (overlap), leaving a 28sec width, more than enough for a 20second window.
I am currently coding a sleep calibration routine so each transmitter wakes precisely before its transmit window and i will share this here eventually.
* Superfluous feature, only need to avoid multiple transmitters colliding packets.
If a transceiver only transmits it is a transmitter, if a transceiver only receives it is a receiver, what then is a repeater that has 2 transceivers with individual roles?
The biggest problem with slow frequency hopping is how the receiver locks on to the sequence. For fully battery operated equipment this is a challenge because the transmitter will need to wait a considerable time between transmissions to conserve battery power, if that time is t seconds and the number of channels is n then the receiver might need to wait in permanent reception on one of those channels at least n*t seconds for a lock, but that assumes there is no interference on that channel, in which case it might have to wait another n*t seconds on another channel, and so on. Control channels are possible, but you're not allowed to give preference to any smaller sets of channels.
How are you proposing to establish a lock? Do you have a network wide clock synchronization system?
Mark.
Every unit has an rtc module with battery
Every unit after wake checks *minute 0-59
Value of *minute corresponds to array index of frequencies 0-59
All rtc are synchronized before installation time.
These rtc have the same address 0x68 , I only need to sync the first with a separate address.
A simple board connected with the first and nth , reset, read values from first sync to nth, rinse and repeat.
So i am only left with avoiding collisions, my current thought is all tnodes sleepxx minutes + random time. Eventually all transmitters will have drifted apart.
Chunks of code to set the frequency;
Change channel every minute
int channelS[60]{921175 ,922700 ,921450 ,922350 ,921125 ,922125 ,922000 ,922525 ,921650 ,922725 ,921275 ,922025 ,921875 ,921325 ,921500 ,921250 ,921575 ,922325 ,922500 ,921350 ,921900 ,921000 ,921550 ,921100 ,922750 ,921700 ,922875 ,921675 ,922425 ,922050 ,922850 ,922100 ,922400 ,922825 ,921050 ,922950 ,922450 ,923000 ,921075 ,922175 ,921925 ,922575 ,921775 ,922675 ,922925 ,922625 ,922150 ,921825 ,921025 ,922375 ,921200 ,921625 ,922600 ,922475 ,921525 ,921225 ,921800 ,922975 ,922225 ,922800};
readDS3231time(&second, &minute);
Frequency = channelS[minute];
initradio();
// The first index of an array is 0 , 0 to 59 of 60 indexes
// Query minute, Minimum is 0 Maximum is 59
// Frequency is a variable inside initradio()
// Assign index [minute] from channelS array to Frequency
// Initialise radio.
Change channel every 20s
int elapsedtime = 20;
readDS3231time(&second, &minute);
int newtime = minute * 60 + second + 1;
if(newtime >= elapsedtime){
x++;
Frequency = channelS[x];
initradio();
elapsedtime = newtime + 20;
if (elapsedtime >= 3599){
elapsedtime = 20;
}
}
if (x > 59) {
x = 0;
}
DS3231 loses or gains 1 second every 7 days so if i use a cheap gps module i can update the seconds every 7th day.
//1 second lost per week, tinygps++ https://github.com/mikalhart/TinyGPSPlus/releases
void loop()
{
if (counter >= 60480) { // 6pkt * 24hrs * 7day = 1008pkt per node * 60nodes = 60480
Serial.begin(4800);
delay(20);
digitalWrite(GPS, HIGH);
delay(3000);
while (Serial.available() > 0) {
if (gps.encode(Serial.read())) {
if (gps.charsProcessed() < 10) {
while (true);
}
else if (gps.time.isValid()) {
byte second = gps.time.second();
Wire.beginTransmission(DS3231_I2C_ADDRESS);
Wire.write(0); // input to start at the seconds register
Wire.write(decToBcd(second)); // set seconds
Wire.endTransmission();
digitalWrite(GPS, LOW);
counter = 0;
}
else
{
while (true);
}
}
}
}
readDS3231time(&second, &minute);
x = minute;
radio.Frequency = channelS[x];
radioconfig();
if (radio.bGetMessage(str) != 0)
{
counter++;
}
}
I have read a lot of documents and will say unlike FCC or ETSI the limit for an antenna gain is 10db on a 20db radio under LIPD in Australia, versus 6db FCC America & 7db Europe ETSI :o
I make reference to 918-926Mhz as there are no penalties for causing or receiving interference within these frequencies in Australia.
After much scrutiny and digging around the Hope module which i believed to be a Semtech module is none other than a Texas Instruments module that is produced under licensing / NDA from the real manufacturer Murata ::) :o Anyone for a brain aneurism!
There is no specific clause in the lucky country that demands a specific frequency spacing on channel frequency, they can be 1kHz to several mHz apart.
Quote from: raggedyanne on October 18, 2016, 03:05:46 AM
After much scrutiny and digging around the Hope module which i believed to be a Semtech module is none other than a Texas Instruments module that is produced under licensing / NDA from the real manufacturer Murata ::) :o Anyone for a brain aneurism!
Which Hope module do you refer to?
The silicon lithograph from murata & semtech are similiar in many ways, it is a chicken or the egg analogy, the sx series are almost identical to the trc from murata (2006).
In this modern time any corp could well be any other corp or it is a licensed design.
Anywho , here is some code for frequency changing , untested at the moment, it looks solid ;D
void ChangeFrequency(unsigned long frequency) //922000(KHZ)
{
typedef union
{
struct
{
byte FreqLSB: 8; //0x00
byte FreqMID: 8; //0x68
byte FreqMSB: 8; //0xE6
} frequency;
unsigned long Freq;
} FreqStruct;
FreqStruct ChangeFrequency;
RADIO_Write(RegOpMode, 0x00); //Putting RADIO to sleep
RADIO_Write(RegOpMode, 0x80); //Switch to LoRa mode
RADIO_Write(RegOpMode, 0x81); //Setting RADIO to standby
while (digitalRead(DIO5) == LOW) //Wait for mode ready
{
}
ChangeFrequency.Freq = (frequency << 11) / 125; //E68000
RADIO_Write(RegFrMsb, FreqMSB);
RADIO_Write(RegFrMid, FreqMID);
RADIO_Write(RegFrLsb, FreqLSB);
RADIO_Write(RegOpMode, 0x85); //Set RADIO to continuous receive
while (digitalRead(DIO5) == LOW) //Wait for mode ready
{
}
}
Quote from: raggedyanne on October 23, 2016, 05:11:43 AM
The silicon lithograph from murata & semtech are similiar in many ways, it is a chicken or the egg analogy, the sx series are almost identical to the trc from murata (2006).
Can you give us two datasheets to compare, one for SX and one for TRC? They look quite different to me. The TRCs are not zero IF as far as I can see which makes them different altogether.
I was comparing the etched silicon, not public datasheets.