Hotspot mode - Apparently stuck in TX

[IW6CNM]

tnx W0RMT
de iw6cnm

[SQ7PTE]

Or maybe there should be a separate file for HotSpot Mode and for ordinary radio?
As a reminder - v0.0.6 no error, v0.0.72 error appears.

[YT5HOK]

Well, I am the one preaching around to be careful when reporting bugs, cause there could be problems on various other places*, not just in OpenGD77 FW, but I can also tell you guys that I never had a single glitch on two generic Chinese hotspots running Pi-Star 4.1.0-RC4/5/6 for months non-stop.

So, don't go blaming Pi-Star for everything now, cause it's counter-productive too.

P.S.
*(Internet, DMR repeaters, even Pi-Star, with 95% chance of bad SD card)

[ad4uu]

Hello Guys,

Here's the latest as I know it. I loaded a fresh pi-star version 3.4.17 with firmware Build 16:26:47 Dec 14 2019. TX hangs immediately.

I then installed the noted stable firmware version 0.0.6. After about 12 hrs now it has been stable. This is also with a pi-0.

I have two Radioddity's radios so I will leave the one alone for now and will do some more experimenting with the other radio.

Thank you all for all your help. Not sure what the right answer is but its different based on user and the firmware and pi-star version running.

Thanks

Dave/AD4UU

[m1dyp]

after i loaded a fresh install. the first this i did was update within pi-star
it may help but glad you have it working

[VK3KYY]

I had a quick look at this, but the TG0 problem isn't that simple to fix.

It partially explains why some people get this bug and some don't, because if the radio does not get any false triggers then everything probably works OK.

Either the problem is caused by a signal being received which the radio miss interprets as TG0 or the code is somehow deciding to send random data to PiStar that contains an empty DMR buffer which would have the DMR ID and TG = 0

Because of bug fixes to the code, its no longer possible to set the Tx DMR ID to 0, so I'll need to modify the firmware so that I can create a transmission on TG0

I have noticed also, that if the radio gets a call on a different Colour Code, it causes it to momentarily flash the green led and at that time the TG is also zero.
So that may be something to do with whats happening

[G4EML]

Roger,

You could use TG0 or ID0 as a way of invalidating a false trigger.

TG 0 or ID 0 are defined as invalid in the DMR Spec and so should never occur in a genuine received signal.

Colin.

[VK3KYY]

Colin

Thats what I started to do, but it looked like there were multiple places this happened, depending on whats causing the problem.

[M0XSI]

Either the problem is caused by a signal being received which the radio miss interprets as TG0 or the code is somehow deciding to send random data to PiStar that contains an empty DMR buffer which would have the DMR ID and TG = 0

For me I only get the TG0 if I've not keyed up.

if I've used the hotspot after some time the radio just sends the last DMR frame I transmitted (Tested by logging all USB traffic to/from the radio), the display will read the last talk or private call group.

I've not captured a TG0 as I don't see that very often.

[kd2lh]

Following up on this. Loaded the 12.31.2019 version of the firmware. Brought it up in hotspot mode, and controlled it with a Pi Zero W.

It locked up within about 10 minutes of booting in the middle of the receipt of data from Brandmeister. It had received the first of three identity packets (with the call sign) during voice reception from the network and locked up. No TG0 or other indication except for live log stopping, the transmitted voice stopping and no further activity with the GD77.

Marc