Missing POCSAG Start Tone

[robrobinette]

Another user and I, both using dual_hs_hat boards using 1.4.3 and Pi-Star 3.4.16 are seeing this behavior. It seems about 1 in 30 POCSAG transmissions are transmitted without the start tone. When this happens our SDR + PDW software will not decode the POCSAG page. The other guy even turned off all other modes and still had the problem. I monitor the hotspot's transmissions using a handi-talkie so I can hear the POCSAG tones. Another user has reported the same issue using a standard simplex ZUMspot with 1.4.3 and 3.4.16.

[juribeparada]

I will need your MMDVMHost log (with log configured with FileLevel=1). This happens after you received too many POCSAG messages at once?

[robrobinette]

Pi-Star_MMDVM-2018-07-18.log

[juribeparada]

Probably the modem has a buffer overflow due to too many POCSAG messages at once. I don't want to increase the buffer size because we are on the RAM limits for duplex boards in the firmware, actually I want to reduce some buffers. I will try to reproduce your issue and try to fix this in the MMDVMHost side, instead of simply increase buffers.

[picchiosat]

Adding this info for your help

Multiple frame are in queue for DMR traffic delay.

Tx start correctly and all messages are decoded in one single tx time. If during this trasmission another frame is added, tx stop and restart immediately without sync tone. Last tx is lost.

Roby IV3JDV

[juribeparada]

Thank you for the info. Yes, yesterday I could reproduce the problem and I found the exact behavior that you describe. Also, if you send long menssages (several) at once, the problem happens. A quick fix is to increase the IO buffer (Globals.h) for example:

const uint16_t TX_RINGBUFFER_SIZE = 2048U; const uint16_t RX_RINGBUFFER_SIZE = 2048U;

but I want to work a better solution, that I hope to be ready for the next release.

[dk5ras]

I also can confirm it. So we're looking forward to the next release :) TNX!!

[g4klx]

It's an odd one. I can't understand why this makes a difference. The output buffers are tested before the output signal is created (at least in the main MMDVM firmware) to ensure that the data buffers are not overrun. The start tone is only created when there is data to send, but the transmitter is off, which is detected by the presence of data to send in the interrupt routine. In fact this is the same logic as used by all the other modes to send the start synchronisation signal (i.e. tone). I'm watching this with interest.

[Lawmanwilly]

I have seen this issue on my STM32 ZUM RADIO 0.9 Board. Is the fix relevant to this board as well ? 73s Lawrence DL1FLW

[g4klx]

I hope so.

[g4klx]

Andy, could you add your change to the main MMDVM firmware? I wonder if this has implications for any of the other modes?

[juribeparada]

I will do Jonathan, but after a little more tests. This happens because in POCSAG mode, the modem switch to IDLE too quickly, and if this happen when IO buffers are full, the TX process exit and is not executed in the next (and last) iteration to empty the m_poBuffer. I think other modes are not affected by this because they have the hang time.

[juribeparada]

I think this issue is fixed now. I also included this fix into MMDVM firmware. Please test and report.

[picchiosat]

Amazing job... One shot...“One kill” 😂😂

[Lawmanwilly]

Hello Andy, i just ran an Update for the ZUM Radio Board it is a STM32 Board, It pulls from https://github.com/g4klx/MMDVM but the version was still from July 5th.

Do i need pull from somewhere else ?

[g4klx]

I don’t update the date unless it represents an update that everyone should get. The Git Id is the guide to the software revision.

Sent from Yahoo Mail for iPhone

On Saturday, July 21, 2018, 11:23, Lawmanwilly notifications@github.com wrote:

Hello Andy, i just ran an Update for the ZUM Radio Board it is a STM32 Board, It pulls from https://github.com/g4klx/MMDVM but the version was still from July 5th.

Do i need pull from somewhere else ?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[Lawmanwilly]

Ok, new info for me..many thanks Ill do some testing now..law