Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
M17 frame description
SmittyHalibut, PE1RXQ
take a look at the NXDN spec, we can borrow some stuff from there.
So. SP5WWP: I lost the last week-and-change's history in IRC, so I don't know what's happened while I was away on holiday.

The work I've done on the protocol is NOWHERE NEAR DONE, but is to a point where I think we'd be better off testing a few ideas and picking the best one, before proceeding too much farther.  What's the status on hardware for testing?
73 de KR6ZY
I'm going back to Poland today, then I can help DB9MAT.
Hi, I'm not a ham yet but interested in getting my license.

Not sure if this is the direction you want to go in but there is a very interesting two papers from gotenna that suggest adding a last sender field to the frame. This is supposed to make it easy to route packets over a mesh. See the paper  [url=""]here[/url]

They also have a paper on a way of flooding the network that may be useful [url=""]here[/url]

If there isn't any interest in meshing then they probably aren't applicable.

Also not sure if there are any patents or up related to them.
Please take a look at my newest proposal (I have edited post #1).

How about sender call + 9 or group ?
How about allow multiple TDMS frame's for data, several radios at same whit own slot ?

Flexibility, data/voice could have headers, so multiple codec could be in use,..

Could there be frame id's so for example instead voice data can be sended GPS or message or data,.. and next time you have slot againg continue whit voice ??

This could be multi codec ?


Forum Jump:

Users browsing this thread: 3 Guest(s)