Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
M17 frame description
#41
Take a look at the thread about Si4463. I can check it on monday. But I think the RX part probably won't work. The API is so fucked up, I have read a lot of complaining about it. I use WDS3 and Zak Kemble's software for generating C header file (4463 config). I'm gonna get an MMDVM board to test the AD chip. We are still working on the hardware update with DB9MAT, so it's not a problem to swap 4463 for 7021.
Reply
#42
The ADF7021 offers programmable sequence detection.
Reply
#43
(12-07-2019, 09:30 AM)SP5WWP link Wrote:
Quote:I didn't realize the 4463 would only send packets, not a stream.

According to the datasheet, it may work without using the internal packet handler (so we send a preamble and then push anything we want in the FIFO). There is a problem still, because this workaround only works for the TX part.
How so?  Can you not turn off the Packet Handler on the receiver and just keep reading from the FIFO?  The documentation didn't spend a lot of time on FIFO without the Packet Handler.

Quote:How about using an ADF7021? $5 on arrow.com. I could get an MMDVM board and test it.
Wait a sec, does the MMDVM already use the ADF7021?  Sorry, I haven't dug into the MMDVM hardware in detail.  Do we have enough control over the existing hardware that the general public could use an MMDVM board as an M17 radio?  To be frank, hardware availability is going to be the thing that kills M17 faster than anything else.  If the general (ham) public can't buy something that will "just work," then it will never get out of the hands of hard-core hackers.  That doesn't mean it's not worth doing, it's just a reality we should understand and expect.

But if the ubiquitous MMDVM hot spots could support M17 with only new software, that goes A LONG WAY to encouraging adoption.

What I'm saying is: Heck yeah, let's look at the ADF7021.  Where can I buy an MMDVM hat that actually supports the hams who designed in? (read: not some random seller on eBay)
73 de KR6ZY
-Mark
Reply
#44
Quote:Can you not turn off the Packet Handler on the receiver and just keep reading from the FIFO?  The documentation didn't spend a lot of time on FIFO without the Packet Handler.

I think it would be best for us to just use the ADF7021 - if it works for DMR and other modes, it will surely work for M17. Did you know that the creators of MMDVM are supporting us? Smile One of them is already here and the rest is on its way.

https://teletra.pl/M17/M17_Layer_2.pdf
Reply
#45
I'm formalizing my protocol proposal into an actual document: https://github.com/sp5wwp/M17_spec/blob/...rotocol.md
73 de KR6ZY
-Mark
Reply
#46
Hi Mark,

Here's my thoughts on your protocol proposal:

1. You might consider applying FEC at the lowest layer possible (i.e., right above the physical layer). Basically, make a "coded PHY" by applying FEC to the lowest-level bits before sending them out over the radio. This should also allow the higher layers to not notice/care about the lower-level FEC parameters (such as FEC algorithm, coding rate, etc.).

2. You mention "LoRa" in the "Broadcast Telemetry" section. I'm not sure what you mean here. LoRa is a physical-layer waveform (i.e., you need a specific chip from Semtech (SX1276, SX1261, etc.) to transmit/receive it). Basically, if the M17 hardware used a LoRa chipset, you could layer the other protocols on top of the LoRa PHY. Do you mean LoRaWAN? That could be potentially interesting in some cases, but there's generally a separate stack for LoRaWAN.

Reply
#47
@faydrus
"Capable of doing the things hams expect" is the key here. We want that functionality (short data service) within M17, not LoRa usage.
Reply
#48
Hi,

I have read on the FAQ list, that you want to use the same identification as in DMR. But this is not really open and ham-like. The process of geting a DMR number needs a request and an administration.

This is not necessary because all licenced amateurs have a unambiguous call composed out of max 6 letters/numbers. Yeasu has got and understood this in his C4FM-system! We don't need a additional identification number. You can translate each call by a simple radix37 (or radix40 as Wojciech might use) operation into a 32 bit number (4 bytes each for a 6 chrs sender-id or recipient-id). You can even extend this to a smart and simple to implement text-compressor to a 2/3 compression rate for each ascii-string or maidenhead-locator! If a resolution of 2m is enough you can put the geographic long. and breadth in only 24 bits each! The time of date down to seconds also needs only 32 bit if you start at a reference year e.g. 2019 and count up.

So please don't waste time and bits for nothing and remember to make it first and foremost comfortable and save for the user! Don't stick to close to existing systems which are not designd for hams. Remember m17 will not be used in a telephone system (well I think it won't be). It should be a smart digital ham-radio! And we have very divergent requirements. Have a look what we really need and build a frame-set around it as compact as possible. For example it is not necessary to send all ham related data in each frame. Instead use a tiny scheduler in the TX. The bit rate within m17 is fast enough! I do that in a 70 or 140 bps-system called STT (text in german) on analog FM-repeaters. Put all the rest available on a tricky FEC redundance. Keep in mind that code spreading to several frames will lead to delays. Too long delays >100ms are not very smart.

Thank you
Reply
#49
Quote:I have read on the FAQ list, that you want to use the same identification as in DMR.
I will update the FAQ today.
Reply
#50
(12-09-2019, 09:12 AM)SP5WWP link Wrote: @faydrus
"Capable of doing the things hams expect" is the key here. We want that functionality (short data service) within M17, not LoRa usage.

Right -- unless you want LoRa as an alternate modulation, there's no point in supporting it.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)