Hello Guillaume,
ID'ing (sending callsign) is of course only done in "NPR" protocol. I've not read your "part 97" rules. Let me know if it matches your local regulations; but if AREDN, DSTAR, C4F and DMR are OK with that, NPR should be OK also.
I'm not an expert on FCC Part 97 and I don't want to derail this conversation but I don't think some of these protocols are legally self-identifying.
No watchdog currently. Here in France, we use a "remote modem" in association with a R-Pi, for remote access. The R-Pi is programmed to reboot the modem once every day. I will see if it's possible to add a standalone and efficient "watchdog". I don't know if my microcontroller has such hardware feature, I will check.
The Raspberry Pi has a watchdog to keep things going there but it would be interesting what your microcontroller can do. Is there any limit of how long a client radio can be in fast or slow mode?
Of course, 2 clients can communicate together via the Master. But the Master or one client cannot wake-up another client. Only the Master has an "active/listening standby" mode, and can be waken-up by a client.
Hmmm.. not being able to wake a client seems to restrict a lot of utility here. If a station cannot wake remote clients (so called "East-West" traffic), it seems this system really only supports "North-South" traffic.
Finally, if the Master is switched OFF, then the clients only send rare "connexion requests", which occupy in total less than 1% of the timeslots.
I'm not sure I understand your point here. If the Master, located on a mountain, is off.. doesn't that mean the system is offline since this system seems like it's designed purely around a strict client/server design. Maybe clients someday could act like adhoc masters for local simplex communications?
- Your advanced document mentions that due to weakness in the FEC
algorithm, maybe using modes "11, 20, or 21". I see there isn't any mode "10" for the 56kS/s symbol signaling rate. Is this a limitation of the modem chip?
I have not provided "mode 10", because my protocol is really not appropriate for such very low datarates. With my current protocol, you would have to wait a very long time in order for one clinet to connect to the Master, because the "discovery slots" do not occur frequently.
Ok. I was just wondering since it sounds like the protocol 10 mode might be more robust.
We are organizing sale to Europe. Today, I'm still not sure if we could sell to US. It would be a great help if someone could organize a sale in the US directly. The BOM is easy to provision, it's given in the documentation. I can help if you have question.
I've sent you an email to your free.fr account.
- Interference on 433Mhz is always going to be a challenge but do you
think it would be possible to add a "scanning" feature to the NPR system so it could go out and listen to X frequencies for Y seconds and come back with a report if those frequencies are quiet? This is something that Wifi has had on it's "channels" and it can be hugely helpful. In an amateur radio deployment, I don't that we would ever want a auto-channel selection feature but being able to initially listen and pick a frequency would be a huge help. The only other option here would be for the operator to deploy an SDR and listen in.
Scanning is possible, the SI4463 has such feature. But I'm not sure I will program that. Like you say, SDR software already exist, and easier to use. And automatic channel selection will not match ham-radio needs.
Ok.. though I think this could be a very important feature in the future. Of the many things I've learned from Amateur Radio is that nothing stays the same forever and interference is unpredictable. People might put up an SDR during an initial site survey to find a clear frequency but they won't leave it there. Having this feature could fill in the gaps...
- With the lower bandwidth design, do you think enhancements could be
made to support full duplex using two radios? Aka.. each transmitter could use multiple time slots for higher performance? I do understand how that makes the overall setup a lot more complex.
It could be possible... but difficult. My design is in the spirit of minimalism. At least, we could develop a "FDD" version, with the Master-repeater station being duplex, and the client stations being half duplex, like 2G/3G phones. But it will add a lot of complexity. I can add this feature to the "wish list", and see if people want it or not. It can be helpfull if you put an NPR Master on a tower which already has a 70cm repeater, full duplex with frequency split. Aggregating several channels : I will not program that, because I don't see the need. If you need more datarate, just use higher symbol rate! If your idea is to strictly respect the "56kBaud" rule of the FCC, then that's a non-sense in my opinion, too crazy. In my opinion, the "occupied radio bandwitdh" rule is much more important than the "Baudrate" rule. I don't see the meaning of a "baudrate" limitation.
Understood and I generally agree with you though having a full duplex system could let some stations run a "super fast" mode ( multiple timeslots ). This could compensate for the lame symbol rate issue we have from the FCC.
- You mentioned that NPR doesn't support IPv6 which is ok for small
deployments but there isn't any mention of MTU. I assume this system supports a RAW MTU of 1518 bytes but maybe it can support smaller or larger MTUs to better deal with the BER rate of the connection?
MTU is 1500, like with Ethernet. In order to be compatible with "lots of things" (IPv6, other IPv4 architectures, static IP, backbone links), I plan to add a "pure ethernet" mode in the following months: the radio protocol will carry "Ethernet frames" instead of currently "IPv4 packets".
Ok though that would add more overhead if you add in the Ethernet header to an IPv4 packet. Another thing I've learned in my networking career, maintain the support for a 1500 byte MTU. Anything less will result in a support nightmare.
That reminds me, on slide 18 of the Intro pdf doc talks about "usable data rate". Is this the payload rate after the raw RF signalling rate or is this the effective TCP/IP payload data rate? Adding a definition in the doc would be helpful.
- I see on the Hackaday page that it looks like the expansion from 7
clients to 15 clients might need different hardware. Would it be a good idea to socket the STM board so the upgrades could be "plug and play"?
That's not possible. The Nucleo L432 board, which I currently use, is already the most powerfull with this "form factor". If I propose a new microcontroller, it would probably be directly integrated to the PCB (LQFP package), so PCB assembly should be made by "automatic PCB assembly" services, or by human with very good soldering skills.
Ah, ok. Looking around, the Nucleo L432 board uses the STM32L432KC chip which looks to be a 24Mhz low power part. Seems something like the NUCLEO-F303K8 might be faster and also in the same form factor? I guess this ultimately comes down to cost of the BOM but hopefully the parts you've designed around will give the system some future upgrades.
--David