[RF induction problem - Solved] Hotspot mode failing after 2/10/2020 updated

[kd2lh]

The last couple of versions released after 2/10 have consistently been failing. I'm cross posting this from a note I added to the 2/16 release feedback since it looks like a problem with handshaking over USB has been introduced. I've enclosed the firmware versions reported from OpenGD77 on the screen with this report.

This fails after just a few minutes of operation:
- - - - - - -

I'm continuing to have problems with this version (as the last version) in hotspot mode on my RpiZeroW.

The firmware version is [ 69d1313 ].

This one is dumping out of conversations that are incoming from Brandmeister. Here's a livelog:

M: 2020-02-17 23:23:51.579 DMR Slot 2, received network end of voice transmission from N1FTE to TG 31371, 2.2 seconds, 0% packet loss, BER: 0.0%
M: 2020-02-17 23:23:55.610 DMR Slot 2, received network voice header from N1FTE to TG 31371
M: 2020-02-17 23:23:56.247 DMR Talker Alias (Data Format 1, Received 6/11 char): 'N1FTE '
M: 2020-02-17 23:23:56.247 DMR Slot 2, Embedded Talker Alias Header
M: 2020-02-17 23:23:56.247 0000: 04 00 56 4E 31 46 54 45 20 *..VN1FTE *
M: 2020-02-17 23:23:56.932 DMR Talker Alias (Data Format 1, Received 11/11 char): 'N1FTE Keith'
M: 2020-02-17 23:23:56.932 DMR Slot 2, Embedded Talker Alias Block 1
M: 2020-02-17 23:23:56.932 0000: 05 00 4B 65 69 74 68 00 00 *..Keith..*
M: 2020-02-17 23:23:57.531 DMR Slot 2, received network end of voice transmission from N1FTE to TG 31371, 2.1 seconds, 2% packet loss, BER: 0.0%
M: 2020-02-17 23:24:05.682 DMR Slot 2, received network voice header from N1FTE to TG 31371
M: 2020-02-17 23:24:05.931 DMR Talker Alias (Data Format 1, Received 6/11 char): 'N1FTE '
M: 2020-02-17 23:24:05.932 DMR Slot 2, Embedded Talker Alias Header
M: 2020-02-17 23:24:05.932 0000: 04 00 56 4E 31 46 54 45 20 *..VN1FTE *
M: 2020-02-17 23:24:06.655 DMR Talker Alias (Data Format 1, Received 11/11 char): 'N1FTE Keith'
M: 2020-02-17 23:24:06.655 DMR Slot 2, Embedded Talker Alias Block 1
M: 2020-02-17 23:24:06.655 0000: 05 00 4B 65 69 74 68 00 00 *..Keith..*

At this point, the PiStar desktop showed the station in red "TX" and the GD77 dumped out of HotSpot mode and back into normal radio mode. "TRX" shows a red "TX DMR Slot 2".

The last stable functioning version was 2/10, which I'm reloading. [a0f4440].

[F1RMB]

Hi Marc,

The last couple of versions released after 2/10 have consistently been failing. I'm cross posting this from a note I added to the 2/16 release feedback since it looks like a problem with handshaking over USB has been introduced. I've enclosed the firmware versions reported from OpenGD77 on the screen with this report.

This fails after just a few minutes of operation:
- - - - - - -

I'm continuing to have problems with this version (as the last version) in hotspot mode on my RpiZeroW.

The firmware version is [ 69d1313 ].

This one is dumping out of conversations that are incoming from Brandmeister. Here's a livelog:

M: 2020-02-17 23:23:51.579 DMR Slot 2, received network end of voice transmission from N1FTE to TG 31371, 2.2 seconds, 0% packet loss, BER: 0.0%
M: 2020-02-17 23:23:55.610 DMR Slot 2, received network voice header from N1FTE to TG 31371
M: 2020-02-17 23:23:56.247 DMR Talker Alias (Data Format 1, Received 6/11 char): 'N1FTE '
M: 2020-02-17 23:23:56.247 DMR Slot 2, Embedded Talker Alias Header
M: 2020-02-17 23:23:56.247 0000: 04 00 56 4E 31 46 54 45 20 *..VN1FTE *
M: 2020-02-17 23:23:56.932 DMR Talker Alias (Data Format 1, Received 11/11 char): 'N1FTE Keith'
M: 2020-02-17 23:23:56.932 DMR Slot 2, Embedded Talker Alias Block 1
M: 2020-02-17 23:23:56.932 0000: 05 00 4B 65 69 74 68 00 00 *..Keith..*
M: 2020-02-17 23:23:57.531 DMR Slot 2, received network end of voice transmission from N1FTE to TG 31371, 2.1 seconds, 2% packet loss, BER: 0.0%
M: 2020-02-17 23:24:05.682 DMR Slot 2, received network voice header from N1FTE to TG 31371
M: 2020-02-17 23:24:05.931 DMR Talker Alias (Data Format 1, Received 6/11 char): 'N1FTE '
M: 2020-02-17 23:24:05.932 DMR Slot 2, Embedded Talker Alias Header
M: 2020-02-17 23:24:05.932 0000: 04 00 56 4E 31 46 54 45 20 *..VN1FTE *
M: 2020-02-17 23:24:06.655 DMR Talker Alias (Data Format 1, Received 11/11 char): 'N1FTE Keith'
M: 2020-02-17 23:24:06.655 DMR Slot 2, Embedded Talker Alias Block 1
M: 2020-02-17 23:24:06.655 0000: 05 00 4B 65 69 74 68 00 00 *..Keith..*

At this point, the PiStar desktop showed the station in red "TX" and the GD77 dumped out of HotSpot mode and back into normal radio mode. "TRX" shows a red "TX DMR Slot 2".

The last stable functioning version was 2/10, which I'm reloading. [a0f4440].

According to the log you posted above, you didn't received the end of voice transmission , or did you copy & paste without it ?

Cheers.
---
Daniel

[kd2lh]

No - I copied the complete log. The "end of voice" never arrived at PiStar. The firmware dumped out to normal OpenGD77 (not hotspot) mode prior to the EOV signal arriving - leaving PiStar locked up and the hotspot inactive.

Sometimes it appears that the Pi overheats after this, possibly indicating excessive polling of the USB port?

Marc KD2LH

[F1RMB]

aHi Marc,

No - I copied the complete log. The "end of voice" never arrived at PiStar. The firmware dumped out to normal OpenGD77 (not hotspot) mode prior to the EOV signal arriving - leaving PiStar locked up and the hotspot inactive.

Sometimes it appears that the Pi overheats after this, possibly indicating excessive polling of the USB port?

Marc KD2LH

I see. Well, if MMDVMHost stops to communicate with the GD's hotspot, after 10 seconds the hotspot mode will exit, and put the GD in "normal" mode.
About the overheating, I don't really know if MMDVMHost starts eating all the CPU% when the network stream breaks. You could check that using 'ps' or 'htop' command line tool (the last the best). I don't think it's due to USB polling, as MMDVMHost polls the USB data each 250ms on normal operation, and since it doesn't send any more data (it seems so) to the GD, it couldn't expects anything in return (as the hotspot exits, nothing as been received from it in the last 10 secs).

Can you remind me the Pi model you're using (sorry, I bet you already told me, but I forgot).

Cheers.
---
Daniel

[kd2lh]

Hi Daniel,
I have both a PiZeroW and a Pi4B in use with the GD77 hotspot.

It fails on both Raspberry Pi models.

The Pi4B has both USB 2 (black) and USB 3 (blue) ports available with the fullsize USB connector used on the standard Radioddity cable. I have to use a short adapter cable for the MicroUSB connector on the PiZero W.

My GD77 radios are about 18 months old. I also have a new one procured about 2 months ago if comparing the two models is needed. So far, I've only been testing with the older GD77 radio.

I have observed the node failing. It happens during an incoming Brandmeister VOIP transmission from the hotspot. It drops a voice packet mid-conversation and the GD77 transmitter stops, yet the PiStar dashboard still shows "TX" mode in red. On other hotspots I can hear the incoming transmission continue through end of voice packet. Live log on the GD77 hotspot never shows processing end of voice and it remains hung.

It's good to know that the hotspot is kept in that mode through active polling.

I'm about to load today's experimental firmware from Roger for testing.

Again, thanks fro looking into this.

[EB3AM]

Hi Daniel,
I have both a PiZeroW and a Pi4B in use with the GD77 hotspot.

It fails on both Raspberry Pi models.

The Pi4B has both USB 2 (black) and USB 3 (blue) ports available with the fullsize USB connector used on the standard Radioddity cable. I have to use a short adapter cable for the MicroUSB connector on the PiZero W.

My GD77 radios are about 18 months old. I also have a new one procured about 2 months ago if comparing the two models is needed. So far, I've only been testing with the older GD77 radio.

I have observed the node failing. It happens during an incoming Brandmeister VOIP transmission from the hotspot. It drops a voice packet mid-conversation and the GD77 transmitter stops, yet the PiStar dashboard still shows "TX" mode in red. On other hotspots I can hear the incoming transmission continue through end of voice packet. Live log on the GD77 hotspot never shows processing end of voice and it remains hung.

It's good to know that the hotspot is kept in that mode through active polling.

I'm about to load today's experimental firmware from Roger for testing.

Again, thanks fro looking into this.

What version of Pi-star are you using?
I've had this same problem, but it's been going well for days.

Well, I specify.
First I had the problem, with an original "RPI 3B" and the Pi-star v3.
I upgraded to the V4rc7 and haven't heard any further TX deactivations.
Yesterday, (I put it in another post) I changed the PI to a neo "Nano PI" and installed version 3 of Pistar (no version 4 compiled on the web). The problem reappeared.
I returned the node to RPI with version 4 this morning.
OpenGD77 version 20200216 on the walkie

73

[F1RMB]

Hi,

Today, finally, I got that kind of problem, for the first time ever.
Using a RPi zero W, with lot of cable everywhere (long USB cords to power the Pi, programming cable + micro-USB OTG cable, etc).
The GD left the hotspot mode (250mW, uncalibrated), and Pi-Star was "stuck" in TX. MMDVMHost was eating 40/50% of the CPU.

Looking at the system messages, here is what I got.

Code: Select all

[54190.983911] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 1, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[54190.983982] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 3, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[54190.984044] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 6, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000021

[54191.032805] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 2, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000021

[54191.032874] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 4, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[54191.032923] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 0, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[54191.062233] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 1, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000021

[54191.062301] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 3, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[54191.062349] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 6, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[54191.070269] usb usb1-port1: disabled by hub (EMI?), re-enabling...
[54191.070309] usb 1-1: USB disconnect, device number 4
[54191.070685] cdc_acm 1-1:1.0: failed to set dtr/rts
[54191.267163] Indeed it is in host mode hprt0 = 00021d01
[54191.597693] usb 1-1: new full-speed USB device number 5 using dwc_otg
[54191.598411] Indeed it is in host mode hprt0 = 00021501
[54191.968849] usb 1-1: New USB device found, idVendor=1fc9, idProduct=0094, bcdDevice= 1.01
[54191.968875] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[54191.968888] usb 1-1: Product: MCU VIRTUAL COM DEMO
[54191.968899] usb 1-1: Manufacturer: NXP SEMICONDUCTORS
[54191.975416] cdc_acm 1-1:1.0: ttyACM1: USB ACM device

[54191.070269] usb usb1-port1: disabled by hub (EMI?), re-enabling...

This is why everything get stuck, as it starts re-enumerating the USB devices.


For the ones that experience such problems, can you take a look (and report here) at the dmesg output when the problem arise ?

Cheers.
---
Daniel

EDIT: I forgot to mention that the RPi was powered by my laptop, with the GD in hotspot mode next to it. Everything in place for EMI problems, on purpose.

[F1RMB]

Again

Code: Select all

[61591.696379] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 7, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000021

[61591.696443] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 1, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.696493] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 4, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.758434] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 5, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000021

[61591.758502] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 6, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.758551] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 2, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000021

[61591.803513] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 7, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.803580] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 1, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.803630] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 4, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.826858] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 5, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.826926] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 6, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.826974] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 2, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.879358] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 7, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.879426] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 1, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.879476] ERROR::handle_hc_chhltd_intr_dma:2218: handle_hc_chhltd_intr_dma: Channel 4, DMA Mode -- ChHltd set, but reason for halting is unknown, hcint 0x00000002, intsts 0x06000001

[61591.891156] usb usb1-port1: disabled by hub (EMI?), re-enabling...
[61591.891196] usb 1-1: USB disconnect, device number 6
[61591.891576] cdc_acm 1-1:1.0: failed to set dtr/rts
[61591.892066] WARN::dwc_otg_hcd_urb_dequeue:639: Timed out waiting for FSM NP transfer to complete on 0
[61592.088313] Indeed it is in host mode hprt0 = 00021501
[61592.368216] usb 1-1: new full-speed USB device number 7 using dwc_otg
[61592.368560] Indeed it is in host mode hprt0 = 00021501
[61592.680265] usb 1-1: New USB device found, idVendor=1fc9, idProduct=0094, bcdDevice= 1.01
[61592.680292] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[61592.680304] usb 1-1: Product: MCU VIRTUAL COM DEMO
[61592.680315] usb 1-1: Manufacturer: NXP SEMICONDUCTORS
[61592.685099] cdc_acm 1-1:1.0: ttyACM1: USB ACM device

[EB3AM]

It certainly seems like a rf issue to the USB cable

I assume you use the walkie series cable, and this cable is not shielded.
You should also look at the OTG adapter that is not the culprit. And the antenna. If you are transmitting the antenna to the walkie will not help either.
Insert an external antenna, and pull the USB cable as far as you can from the antenna cable. If you have the ability to make a USB shielded cable, it would be much better. At the very least, try putting ferrites on each end of the USB cable.

[F1RMB]

Hi,

It certainly seems like a rf issue to the USB cable

I assume you use the walkie series cable, and this cable is not shielded.
You should also look at the OTG adapter that is not the culprit. And the antenna. If you are transmitting the antenna to the walkie will not help either.
Insert an external antenna, and pull the USB cable as far as you can from the antenna cable. If you have the ability to make a USB shielded cable, it would be much better. At the very least, try putting ferrites on each end of the USB cable.

it's exactly what I'm trying to demonstrate, as I never experienced what Marc (and few others) have.
Since the last USB re-enumeration, I switched to an external power supply (trying to not move the other setup, and eliminate the laptop as a feeder), and didn't experienced USB problem... yet

Cheers.