Random receive termination

Help with YSF / Fusion issues
Post Reply
KD7F
Posts: 10
Joined: Sat Feb 13, 2021 10:06 pm

Random receive termination

Post by KD7F »

I have been using YSF2P25 quite a bit and I have noticed that occasionally while I am transmitting the hotspot will act like I unkeyed when I hadn't. The stations I was talking with say my transmission just stops. I now keep an eye on the dashboard and when I see the drop I immediately unkey and key down again and the hotspot receive resumes. Sometimes the receive terminates after a minute or more...other times it may only be after 5 to 10 seconds. The timing seems to be random. My BER as indicated by the dashboard is 0.1% and the audio sounds clean to the stations I am working prior to the receive termination. The dashboard indicates the received signal level is S9 + 46dB (-47dBm)

I have seen this behavior with the YSF Parrot but it doesn't seem to happen as often with the Parrot. Due to the random nature though I can't state that as an absolute fact.

Originally I had the MMDVM_HS hat on a Pi zero. I took that hat and put it on a Pi 3B+ to see if a direct LAN connection might have an impact on the behavior - it didn't. In both cases I was running the 4.1.4 Pi Star image with the latest update. The MMDVM hat firmware is the latest: 1.5.2. The radio I am using is a Yaesu FT3D. The behavior doesn't seem to be related to being in DN or VW mode (of course I have to run VW mode when using YSF2P25).

Since I have seen this behavior with the YSF Parrot I assume that the problem isn't totally related to internet network issues. If my observations about it happening less often with the Parrot are real I guess there could be some connection.

I have looked at the transmit spectrum of the hotspot and while there seems to be a bit of peaking in the local oscillator noise floor it does not look like the LO PLL is close to instability. I am operating the hotspot at 439.425MHz as suggested by our frequency coordinator. At this frequency the PLL tune line is about 0.8V. According to the ADF7021 spec sheet the tune voltage should be in the range 0.2-2V so 0.8V isn't close to the rail.

I have another MMDVM hat ordered and will see if the behavior changes with a different hat, but I am wondering if anyone else has noticed this random receive termination behavior.

I should mention that there is another "oddity" that my current setup on the Pi 3B+ has. When I power up or reboot, the YSFGateway service is not running. Going to the configuration page and just hitting any Apply Changes button will start the YSFGateway service. There is another thread (YSFGateway not starting) where I have been asking about this behavior. When I was using the Pi zero, I didn't have this issue.

73, Jim KD7F
KD7F
Posts: 10
Joined: Sat Feb 13, 2021 10:06 pm

Re: Random receive termination

Post by KD7F »

I received the second MMDVM_HS hat and it has the same behavior as the first, randomly dropping receive.

I re-imaged the uSD card on the Pi3B+ with the 4.1.4 Pi-Star version and when properly configured, the YSFGateway service would never start. I followed what I read others have done: Start with the 4.1.2 image, then upgrade using the Pi-Star software upgrade functionality to 4.1.4 and that solved the YSFGateway not starting problem. Everything works but I still have the random receive dropping issue in YSF2P25.

I do notice that the Kernel is now an earlier version (4.19.97-v7+) so I believe there is some OS/Pi-Star interaction issue that makes the 4.1.4 image problematic with the YSFGateway not starting issue with the later OS version. Others have seen the same issue but I don't know how prevalent the issue may be.

73, Jim
KD7F
Posts: 10
Joined: Sat Feb 13, 2021 10:06 pm

Re: Random receive termination - New information

Post by KD7F »

I have been continuing to try to figure out what is going on with the hotspot dropping my receive signal. Since I have two hotspots now I decided to set both up into the YSF parrot and see if both would experience the drops at the same time. That might implicate my FT3D radio as a potential cause. Well that is not what I found. First I should explain that I have MMDVM_HS hats on a Pi zero W and on a Pi 3B+. Both hats are running the 1.5.2 firmware version and both Pi's are running the 4.1.4 image updated to the latest (as of two days ago) Pi Star software. The Pi 3B+ hotspot runs into the dropping issue more frequently than the Pi zero hotspot for some reason. I swapped the hats and it made no difference. I should also mention that the Pi zero was connected via WiFi of course but I had an Ethernet connection to the 3B+ hotspot. Both connected to the same router.
Anyway, looking at the logs at one of the drops, we see the following:

Pi 3B+:

M: 2021-03-01 19:18:24.309 YSF, received RF header from KD7F to ALL
M: 2021-03-01 19:21:08.597 YSF, transmission lost from KD7F to ALL , 164.3 seconds, BER: 0.1%, RSSI: -47/-47/-47 dBm
M: 2021-03-01 19:21:09.305 YSF, received RF late entry from KD7F to ALL
M: 2021-03-01 19:21:15.805 YSF, received RF end of transmission from KD7F to ALL , 6.6 seconds, BER: 0.3%, RSSI: -47/-47/-47 dBm

Pi Zero:

M: 2021-03-01 19:18:24.435 YSF, received RF header from KD7F to ALL
M: 2021-03-01 19:21:15.816 YSF, received RF end of transmission from KD7F to ALL , 171.6 seconds, BER: 0.1%, RSSI: -47/-47/-47 dBm

Notice that after the transmission lost message on the 3B+ there is another "received RF late entry" message. The interesting thing is that this loss and late entry did not cause any apparent loss of data in the parrot playback. I imagine that this behavior could be happening a lot and never be noticed unless one was staring at the live log or the dashboard while using the hotspot. In the YSF mode, the transmission lost event doesn't interrupt anything. This is NOT the case in the YSF2P25 case. When the transmission lost event occurs, it stops the transcoding and it will not resume again until another RF header is received - thus my need to unkey and rekey to continue transmission to the P25 talk group. In YSF2P25 there is no late entry event in the log file.

I repeated the test half a dozen times and saw the same results each time. Here is another run:

3B+:

M: 2021-03-01 20:56:06.098 YSF, received RF header from KD7F to ALL
M: 2021-03-01 20:57:09.791 YSF, transmission lost from KD7F to ALL , 63.7 seconds, BER: 0.1%, RSSI: -47/-47/-47 dBm
M: 2021-03-01 20:57:10.298 YSF, received RF late entry from KD7F to ALL
M: 2021-03-01 20:58:58.298 YSF, received RF end of transmission from KD7F to ALL , 108.1 seconds, BER: 0.1%, RSSI: -47/-47/-47 dBm

Zero:

M: 2021-03-01 20:56:06.248 YSF, received RF header from KD7F to ALL
M: 2021-03-01 20:58:58.320 YSF, received RF end of transmission from KD7F to ALL , 172.3 seconds, BER: 0.1%, RSSI: -47/-47/-47 dBm

I believe the transmission lost message is somehow being generated falsely due to something occurring in the Pi Star firmware or its interaction with the hat firmware. In all my testing into the parrot I never saw the Pi zero hotspot experience the transmission lost event, however when I used the Pi zero hotspot with YSF2P25 to P25 TG 10888 later in the evening the transmission lost event happened multiple times during a 15 minute QSO. So that might indicate some inter-process timing problem as the cause since the data was flowing to the network.

There is one difference between the Kernel version shown on the two hotspots. The Pi 3B+ indicates "5.10.11-v7+" while the zero indicates "5.10.11+" . I have no idea what the "v7" would indicate and haven't tried to do any searching to find out...

I guess my next step is to try looking at the source code to see if I can learn anything, but if the developers can use the above observations and find the problem that would of course be great!

73, Jim KD7F
KE7FNS
Pi-Star Team
Posts: 1823
Joined: Wed Apr 17, 2019 11:11 pm

Re: Random receive termination - New information

Post by KE7FNS »

KD7F wrote: Wed Mar 03, 2021 7:55 pm There is one difference between the Kernel version shown on the two hotspots. The Pi 3B+ indicates "5.10.11-v7+" while the zero indicates "5.10.11+" . I have no idea what the "v7" would indicate and haven't tried to do any searching to find out...
The reason for the difference is because the processors are different and take different instruction sets.

The RPi Zero W uses the ARMv6Z instruction set. It can only run the standard kernel ie v6

The RPi 3B+ uses the ARMv8-A instruction set however Pi-star is a built on a 32bit Raspberry Pi OS, so it dumbs down to the ARMv7-A instruction set which the processor can also use.

I don't have any idea if Pi-star will ever move to a full 64-bit ARMv8 OS, but I doubt it.


I seriously doubt the kernel differences are directly related to your issues. I've read through your report and I think it is just a result of the hats you are using.
If someones previous actions are any indication of their future actions, then I predict the deletion and removal of access will happen at any moment. 7-11-2020.

"07/13/20 This Website Has Been Taken Down" ... again :lol:
KD7F
Posts: 10
Joined: Sat Feb 13, 2021 10:06 pm

Re: Random receive termination

Post by KD7F »

Thanks for the information on the Kernels.

Are there known issues with some of the MMDVM_HS hats?

The two I have are from different manufacturers but are of similar design. The first one had a bead that was supposed to be loaded in a 3.3V supply filter but which was actually loaded in the spot for the external inductor for the second VCO in the ADF7021. The inductor that was supposed to be the external inductor for the VCO was loaded in the supply filter. Apparently they had a run of boards with the reels swapped on the pick and place machine. I put the bead back into the supply filter and put an 18nH inductor I had in stock in as the VCO inductor which made operation on VHF possible, but of course the rest of the parts in the path from the antenna to the 7021 were loaded for UHF operation, which is where I am actually operating it.

The second MMDVM_HS hat seems to operate properly (was loaded correctly, although the board layout is slightly different. I am sure both came from China, via Amazon.

I guess I am still not convinced it is totally a hat problem. I have only operated with the YSF and YSF2P25 modes and only the YSF2P25 has the issue with the transmission loss stopping the whole process until the next keydown. I guess I don't care if the transmission loss event is occurring if it doesn't prematurely end my transmission to the reflector I am working through. Are others using YSF2P25 without experiencing these interruptions using MMDVM_HS hats?
KE7FNS
Pi-Star Team
Posts: 1823
Joined: Wed Apr 17, 2019 11:11 pm

Re: Random receive termination

Post by KE7FNS »

KD7F wrote: Wed Mar 03, 2021 10:28 pm Are there known issues with some of the MMDVM_HS hats?
Yeah, some board designs have flaws. I've got one that is missing a 5 volt trace completely. Its marked as 5 volts on the silkscreen, but it doesn't connect anywhere. It doesn't really effect operation, but still. Also the Jumbospot boards are missing connections for automatically putting the STM32 into bootloader mode, they are also missing pads to manually put the STM32 into bootloader mode too.

I know the official designers have stated that the cloners use lower quality parts, as to how that effects the entire system, I really don't know.
Maybe someone could test and report on the differences with some actual data.
KD7F wrote: Wed Mar 03, 2021 10:28 pm The two I have are from different manufacturers but are of similar design. The first one had a bead that was supposed to be loaded in a 3.3V supply filter but which was actually loaded in the spot for the external inductor for the second VCO in the ADF7021. The inductor that was supposed to be the external inductor for the VCO was loaded in the supply filter. Apparently they had a run of boards with the reels swapped on the pick and place machine. I put the bead back into the supply filter and put an 18nH inductor I had in stock in as the VCO inductor which made operation on VHF possible, but of course the rest of the parts in the path from the antenna to the 7021 were loaded for UHF operation, which is where I am actually operating it.

The second MMDVM_HS hat seems to operate properly (was loaded correctly, although the board layout is slightly different. I am sure both came from China, via Amazon.
Kinda above my paygrade. I can follow along, but if I would of had your hat I wouldn't of been able to figure that out myself.

Thats pretty interesting that it seems to be someone at the factory put the wrong reel in the wrong spot. It makes perfect sense though. It makes me wonder how many people have defective boards and don't even realize it.
KD7F wrote: Wed Mar 03, 2021 10:28 pm I guess I am still not convinced it is totally a hat problem. I have only operated with the YSF and YSF2P25 modes and only the YSF2P25 has the issue with the transmission loss stopping the whole process until the next keydown. I guess I don't care if the transmission loss event is occurring if it doesn't prematurely end my transmission to the reflector I am working through. Are others using YSF2P25 without experiencing these interruptions using MMDVM_HS hats?
I really don't know, I don't use those modes.

But I think it is a hat issue. The reasoning is something is telling MMDVMHost there has been a loss of signal.

https://github.com/g4klx/MMDVMHost/blob ... l.cpp#L111

Code: Select all

if (type == TAG_LOST && m_rfState == RS_RF_AUDIO)
That had to evaluate to true and m_rssi had to have been not equal to zero, otherwise it wouldn't of written that message to the logs. The hard part is figuring out why it ended up at that message in the code.

I know YSF has been weird with MMDVM_HS hats, some users report some radios just don't work. Yaesu also won't release what they do differently that makes their stuff incompatible, they just state that their radios support their official radios and repeaters, and don't support 3rd party devices.

This guy even went and bought an official board and it still didn't work correctly with his radio. I think he eventually just gave up.
https://github.com/juribeparada/MMDVM_HS/issues/127

I guess you could file some issue reports on the MMDVMHost and MMDVM_HS github, and maybe get some responses from the developers themselves.
If someones previous actions are any indication of their future actions, then I predict the deletion and removal of access will happen at any moment. 7-11-2020.

"07/13/20 This Website Has Been Taken Down" ... again :lol:
KD7F
Posts: 10
Joined: Sat Feb 13, 2021 10:06 pm

Re: Random receive termination

Post by KD7F »

Thanks for the information. I will continue on my quest to get it understood if not working...
W9NAP
Posts: 1
Joined: Sun Jun 20, 2021 7:55 am

Re: Random receive termination

Post by W9NAP »

I have a MMDVM_HS hat on a Pi zero that worked without flaw for years. At some point along the way, I got busy and left it running unused. When I went to use it again, I found that it had all the symptoms you describe, including the log entries. But it was much worse: I couldn't make a complete transmission more than a couple seconds without being dropped.

I reflashed the OS, got a new SD card, re-soldered the antenna mount, etc., all to no avail. And then I happened upon this article regarding calibrating the radio. After that procedure, my hotspot is now back to normal. So it seems that the radio drifted over time, so the offset needed a tweak.

Not sure if yours is the same issue (seems odd with two different hats), but it's worth a try.

https://www.george-smart.co.uk/2020/06/ ... tar-mmdvm/
Post Reply