Thanks Johnathan. I’ll be working a things a bit today and this evening.
On Dec 8, 2018, at 12:36 PM, Jonathan Naylor via Groups.Io <firstname.lastname@example.org> wrote:I’ll mainly be concentrating on D-STAR, YSF and DMR since that’s what I have test gear for.
This version should at least allow you to test with the UDRC and iron out any bugs.I have a serial code fix for the read side of things. The transplanted MMDVMHost code has different semantics than the code for MMDVM-UDRC expects. The MMDVMHost code blocks when it receives an initial chunk of data and then waits indefinitely until it reads the entire buffer length requested. This doesn’t work for MMDVM-UDRC because it blocks the main event thread waiting for more serial data that will never come.
I did some significant remodeling of the serial input code so that it reads a little bit more judiciously and uses the length field of the MMDVM frame to figure out how much to ask the OS to read for it. This seems to solve the problem. I’ll PR it soon so you can at least take a look at it.
Remember that the DMR in this version is simplex only. Using the UDRC or similar hardware makes it impossible to have the type of synchronisation that duplex DMR repeating requires.I understand the synchronization issues surrounding the DMR time slots. I’d like to get the rest of the protocols working correctly and then Bryan and I have had recurring ideas on how we could potentially deal with that issue. I’m curious, though, how tight is the timing issue time-wise. Does the PTT have to cycle in 1ms, 10ms, 100ms? I’m assuming it’s the time from the preamble in that slot to when actual data begins to flow.
Annaliese McDermond (NH6Z)