Possible HotSpot bug
Possible HotSpot bug
Hi,
In hotspot mode if the person transmitting has packet loss the openGD77 will stop transmitting but pi-star will still show as being in TX.
if I connect a MMDVM_HS_HAT on the same pistar version to the same talk group I hear the whole transmission
This doesn't impact the next transmission on channel everything is normal.
There doesn't seem to be anything in the MMDVM log, the transmission stopped just after 20:18
M: 2021-03-24 20:17:52.593 DMR Slot 2, received network voice header from 2E0UKL to TG 23511
M: 2021-03-24 20:17:53.180 DMR Talker Alias (Data Format 2, Received 6/13 char): '2E0UKL'
M: 2021-03-24 20:17:53.180 DMR Slot 2, Embedded Talker Alias Header
M: 2021-03-24 20:17:53.180 0000: 04 00 9A 32 45 30 55 4B 4C *...2E0UKL*
M: 2021-03-24 20:17:53.899 DMR Talker Alias (Data Format 2, Received 13/13 char): '2E0UKL Martin'
M: 2021-03-24 20:17:53.899 DMR Slot 2, Embedded Talker Alias Block 1
M: 2021-03-24 20:17:53.899 0000: 05 00 20 4D 61 72 74 69 6E *.. Martin*
M: 2021-03-24 20:20:30.385 DMR Slot 2, received network end of voice transmission from 2E0UKL to TG 23511, 165.0 seconds, 4% packet loss, BER: 0.0%
Is there a better way to get a log for this? I'm using the current version of the firmware available in the CPS (D2021.03.21.01) Also the same with my other radio running on (D2020.11.12.01)
Sorry for such a bad bug report I'm just not sure how to collect the logging from the radio if it exists.
Simon
In hotspot mode if the person transmitting has packet loss the openGD77 will stop transmitting but pi-star will still show as being in TX.
if I connect a MMDVM_HS_HAT on the same pistar version to the same talk group I hear the whole transmission
This doesn't impact the next transmission on channel everything is normal.
There doesn't seem to be anything in the MMDVM log, the transmission stopped just after 20:18
M: 2021-03-24 20:17:52.593 DMR Slot 2, received network voice header from 2E0UKL to TG 23511
M: 2021-03-24 20:17:53.180 DMR Talker Alias (Data Format 2, Received 6/13 char): '2E0UKL'
M: 2021-03-24 20:17:53.180 DMR Slot 2, Embedded Talker Alias Header
M: 2021-03-24 20:17:53.180 0000: 04 00 9A 32 45 30 55 4B 4C *...2E0UKL*
M: 2021-03-24 20:17:53.899 DMR Talker Alias (Data Format 2, Received 13/13 char): '2E0UKL Martin'
M: 2021-03-24 20:17:53.899 DMR Slot 2, Embedded Talker Alias Block 1
M: 2021-03-24 20:17:53.899 0000: 05 00 20 4D 61 72 74 69 6E *.. Martin*
M: 2021-03-24 20:20:30.385 DMR Slot 2, received network end of voice transmission from 2E0UKL to TG 23511, 165.0 seconds, 4% packet loss, BER: 0.0%
Is there a better way to get a log for this? I'm using the current version of the firmware available in the CPS (D2021.03.21.01) Also the same with my other radio running on (D2020.11.12.01)
Sorry for such a bad bug report I'm just not sure how to collect the logging from the radio if it exists.
Simon
Re: Possible HotSpot bug
The PiStar dashboard display is not a 100% reliable indication of whether the person is still actually transmitting.
The way PiStar gets its data in terribly inefficient, it constantly reads the MMDVMHost log file and scans it for changes which it recognises and it uses this data to update the display.
I've had problems with my duplex MMDVM_HS hotspot where the PiStar dashboard would say the other station was still transmitting, but the MMDVM_HS hotspot would have stopped transmitting.
You can get more MMDVMHost to log more data, but because PiStar uses the log file to update the display, you may find that makes things worse.
Look in the MMDVMHost configuration file options, and you can get it to log every DMR frame it sends to the hotspot
BTW.
The hotspot has not been changed in ages, but some changes associated with power saving, had an impact on the USB, so you could re-test an old stable version e.g. I think there is one in October 2020
You also didn't say which type of RPi board you are using. There is a big difference in performance between, the RPI Zero W and the RPi4
Also, I presume you have read all the notes about only using an external antenna, and also protecting the USB cable from RF injection.
And you also didn't say what type of radio you are using.
The way PiStar gets its data in terribly inefficient, it constantly reads the MMDVMHost log file and scans it for changes which it recognises and it uses this data to update the display.
I've had problems with my duplex MMDVM_HS hotspot where the PiStar dashboard would say the other station was still transmitting, but the MMDVM_HS hotspot would have stopped transmitting.
You can get more MMDVMHost to log more data, but because PiStar uses the log file to update the display, you may find that makes things worse.
Look in the MMDVMHost configuration file options, and you can get it to log every DMR frame it sends to the hotspot
BTW.
The hotspot has not been changed in ages, but some changes associated with power saving, had an impact on the USB, so you could re-test an old stable version e.g. I think there is one in October 2020
You also didn't say which type of RPi board you are using. There is a big difference in performance between, the RPI Zero W and the RPi4
Also, I presume you have read all the notes about only using an external antenna, and also protecting the USB cable from RF injection.
And you also didn't say what type of radio you are using.
Re: Possible HotSpot bug
Thanks I'll try get the full log.
I confirmed he was still transmitting with another separate hotspot. the transmission ended with the "received network end of voice transmission" line in the log
with no packet loss I get no interruption. it's like when the hotspot loses the packet(s) it never recovers.
I'll check the version from 2020.
Wow I did a crap job with this report, I'm sorry
It's on a Pi 3b as is my other hotspot.
I do have a pi4 I can test with.
Both of the test radios is are GD77 I do have a DM1801 I can test with too if I can find an adaptor.
I am using an external antenna, and the USB cable has a choke on it. I have no issues apart from transmissions with packet loss in them. I've been using hotspot mode since you introduced it.
Kind Regards
Simon
I confirmed he was still transmitting with another separate hotspot. the transmission ended with the "received network end of voice transmission" line in the log
with no packet loss I get no interruption. it's like when the hotspot loses the packet(s) it never recovers.
I'll check the version from 2020.
Wow I did a crap job with this report, I'm sorry
It's on a Pi 3b as is my other hotspot.
I do have a pi4 I can test with.
Both of the test radios is are GD77 I do have a DM1801 I can test with too if I can find an adaptor.
I am using an external antenna, and the USB cable has a choke on it. I have no issues apart from transmissions with packet loss in them. I've been using hotspot mode since you introduced it.
Kind Regards
Simon
Re: Possible HotSpot bug
No worries
Try the older versions prior to the power saving.
Looking at the release log, the last version prior to the power saving was
https://github.com/rogerclarkmelbourne/ ... 0.12.29.02
But you could go back a bit further
Try the older versions prior to the power saving.
Looking at the release log, the last version prior to the power saving was
https://github.com/rogerclarkmelbourne/ ... 0.12.29.02
But you could go back a bit further
Re: Possible HotSpot bug
I have the last stable installed from 19th October it'll likely be tomorrow before I get any more traffic on the group. but I'm ready with my logging!
Thanks again,
Simon
Thanks again,
Simon
Re: Possible HotSpot bug
OK.
These sorts of bugs can take ages to replicate
These sorts of bugs can take ages to replicate
Re: Possible HotSpot bug
ok the issue isn't there in the October build. It survives up to 30% packet loss without early termination of the transmission.
Same radio, same cable, same antenna setup same pi3b pi-star 4.1.4 build.
Same radio, same cable, same antenna setup same pi3b pi-star 4.1.4 build.
Re: Possible HotSpot bug
Can you give me the hotspot firmware version (the one displayed in the Pi-Star dashboard) ?.
Cheers.
---
Daniel
Re: Possible HotSpot bug
Hi Daniel,
the working version displays OpenGD77: v0.1.4 in the dash.
The version I noticed the issue in is the current public version that displays v0.1.6
I'd not upgraded my hotspot radio for ages so it could have been broken for a while.
Simon
the working version displays OpenGD77: v0.1.4 in the dash.
The version I noticed the issue in is the current public version that displays v0.1.6
I'd not upgraded my hotspot radio for ages so it could have been broken for a while.
Simon
Re: Possible HotSpot bug
Can you test the version immediately prior to when power saving was introduced,
https://github.com/rogerclarkmelbourne/ ... 0.12.29.02
as we'll need to rule out the power saving code
FYI.
The radio should not enter power saving when its in hotspot mode, but there were a lot of changes introduced with the power saving, and one of those may be causing this