Hotspot mode - Apparently stuck in TX

[SQ7PTE]

I use 3B+
I already thought that we are few but I see that there are a few people who use GD77 as a HotSpot
I have already lowered the voltage supplying the radio, but nothing helped.
The radio has a constant voltage - I do not use a battery)

[VK3KYY]

OK

I have a B+ but I don't know if PiStar is installed on it at the moment.

I ran the hotspot on TG91 for about 4 hours with no problem.

But I had to stop the test, because I needed to use my radio with the debugger attached it it, to fix the bugs the PR from Colin for the Tone scan.

[SQ7PTE]

Yes Roger. I tested yesterday for a very long time about a few hours and nothing, everything was OK
But as once, the second is happening, it is the awareness that it may be the third time to shoot a man
Maybe you need to look for the reason in the settings?
I personally changed the settings in these pi-star areas
I don't remember what values should be original
I will tell you that in version 0.0.6 there is no problem - at least for me ...

[VK3KYY]

OK.

I won't have time to look at this until tomorrow

[YT5HOK]

Sorry Roger for the late reply, I was sleeping.
I use Raspberry Pi 3A and all settings are default, except for those mandatory to change.
Sometimes it takes 5-6 hours to happen, even more. Has to happen if you run it one day in the afternoon and then leave it overnight.

[VK3KYY]

Sometimes it takes 5-6 hours to happen, even more. Has to happen if you run it one day in the afternoon and then leave it overnight.

umm. OK. This is going to take some time to fix

[kd2lh]

The time to failure is random, from several minutes to seconds.

It has sat for hours without failing. But, often within a minute to seconds of properly receiving a local RF transmission, and then receiving data from the VOIP infrastructure, it fails.

The radio transmitter turns off at the end of VOIP received packets, but the red "TX" remains on in PiStar and nothing further is processed through the radio.

I have been using a newer Pi 4B in both Wifi and wired Ethernet mode, observing the failure on both.

It fails pretty consistently after using the 9990 Parrot (not talk group, but private ID call).

I use 3137, 31371, 31377 and 98977 talkgroups configured as static in Brandmeister.

It has failed without regard to which talkgroup or static ID was used last.

This is consistent on the Pi4b. I have a Pi Zero on order and will be testing on that card when it arrives in a week or so.

[VK3KYY]

Someone needs to work out how to make this go wrong.

In the previous versions lockup’s were caused by specific timings of signals.

E.gl rapid pressing if the PTT

However if you try that on BM you will get blocked, so the only way to tests like that is on DMR+ or possibly TGIF

[kd2lh]

This will fail on my system within seconds to minutes after receipt of a normal incoming RF transmission of any normal length. Successfully do a moderate length (8-10 second) call to the Parrot and the hotspot will sit for some time, then lockup on a subsequent incoming transmission from VOIP infrastructure (Brandmeister). PiStar generally shows the call and talkgroup of the last successful transmission when the lockup happens.

Using Config to restart things will not reset the TX mode. I have to reboot PiStar completely, and re-initialize the GD77 before it will operate properly again. Just resetting PiStar (by using "Update" for example) comes back up with the TX red and locked that way.

[m1dyp]

just installed pi-star on a 2gb card, popped it in a rpi3b, took me ages to get the 'wifi' working but once that was sorted, configured the bits i had to, selected zumspot libre and saved, then did UPDATE from the dashboard and found i could select 'OpenGD77 DMR hotspot (USB)'

so far everthing is working fine, nothing changed except the bits you have to

I will leave it running..........