17 Jun
2019
17 Jun
'19
11:38 p.m.
Hello Guillaume,
Ok. I was just wondering since it sounds like the protocol 10 mode
might be more robust.
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...
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.
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.
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
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. 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. - 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. - 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". - 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.