Update 9th Jan 2020
Re: Update 9th Jan 2020
working ok on android and win 7 with blue dv
Re: Update 9th Jan 2020
I am running the firmware with your fix, it seems to be working well, but then
then your version before worked ok for me on Windows 10 with the latest beta version
of BlueDV
then your version before worked ok for me on Windows 10 with the latest beta version
of BlueDV
Re: Update 9th Jan 2020
Hi Mike,
That's why, I think, this didn't happen all the time.
Cheers.
The problem I've found with BlueDV (Windows preBeta, didn't tried older ones), is if you start DMR and connect a TG where a QSO is already running, BlueDV "forget" to set the hotspot in DMR mode (it let it IDLE).
That's why, I think, this didn't happen all the time.
Cheers.
Re: Update 9th Jan 2020
I will try to contact the author of BlueDV, because BlueDV does not seem to send send exactly the same data as MMDVMHost (PiStar).
I presume BlueDV intended to copy what MMDVMHost does, but either took some shortcuts or didn't implement everything.
I presume BlueDV intended to copy what MMDVMHost does, but either took some shortcuts or didn't implement everything.
Re: Update 9th Jan 2020
For my firmware from January 9, when the hotspot is working in the MMDVM setting, unfortunately the connection with Pi-star breaks and the inscription Waiting to Pi-star appears, which sometimes disappears after a while, but the work is hotspot is no longer natural. Reverting to the FW version from January 6 restores normal hotspot operation when working with MMDVM. Also, probably something is wrong with this version.
Re: Update 9th Jan 2020
Hi,
On the first next MMDMHost frame, it will goes back to hotspot mode (the Waiting... screen), waiting for the next MMDVMHost communication frame to display the any hotspot activity information (IDLE, RX, TX...).
MMDVMHost keeps sending frames as long as it run (getStatus), even when it's IDLEing.
Cheers.
In MMDVM mode, the code detects if MMDVMHost is still running. If for whatever reason it stops, after a while it will leave hotspot and goes back to normal operation mode.SO5AJG wrote: ↑Thu Jan 09, 2020 10:14 pmFor my firmware from January 9, when the hotspot is working in the MMDVM setting, unfortunately the connection with Pi-star breaks and the inscription Waiting to Pi-star appears, which sometimes disappears after a while, but the work is hotspot is no longer natural. Reverting to the FW version from January 6 restores normal hotspot operation when working with MMDVM. Also, probably something is wrong with this version.
On the first next MMDMHost frame, it will goes back to hotspot mode (the Waiting... screen), waiting for the next MMDVMHost communication frame to display the any hotspot activity information (IDLE, RX, TX...).
MMDVMHost keeps sending frames as long as it run (getStatus), even when it's IDLEing.
Cheers.
Re: Update 9th Jan 2020
I've merged Daniel's latest fix for BlueDV, and also done a temporary fix for the version not showing in PiStar.
I don't think there is any need to change PiStar to resolve the version number display, as the "description" which is reported to PiStar was already correct, i.e "OpenGD77 Hotspot vxx.yy.zz"
The problem was a biproduct of the changes to display the hotspot version when SK1 was pressed, which can be resolved so that PiStar does not need to be changed.
I don't think there is any need to change PiStar to resolve the version number display, as the "description" which is reported to PiStar was already correct, i.e "OpenGD77 Hotspot vxx.yy.zz"
The problem was a biproduct of the changes to display the hotspot version when SK1 was pressed, which can be resolved so that PiStar does not need to be changed.
- Attachments
-
[The extension sgl has been deactivated and can no longer be displayed.]