Page 3 of 4

Re: Update 9th Jan 2020

Posted: Thu Jan 09, 2020 12:49 pm
by m1dyp
working ok on android and win 7 with blue dv

Re: Update 9th Jan 2020

Posted: Thu Jan 09, 2020 12:51 pm
by F1RMB
m1dyp wrote:
Thu Jan 09, 2020 12:34 pm
in hotspot mode not seen the debug screen before :o
;)

Re: Update 9th Jan 2020

Posted: Thu Jan 09, 2020 12:52 pm
by F1RMB
F1CXG wrote:
Thu Jan 09, 2020 12:43 pm
Thanks Daniel, I'll try it on BlueDv Win7 & Android ;)
Thanks Thierry, don't forget to select the hotspot mode accordingly.

Re: Update 9th Jan 2020

Posted: Thu Jan 09, 2020 12:52 pm
by F1RMB
m1dyp wrote:
Thu Jan 09, 2020 12:49 pm
working ok on android and win 7 with blue dv
Thanks Ken.

Re: Update 9th Jan 2020

Posted: Thu Jan 09, 2020 1:03 pm
by KU4ZD
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

F1RMB wrote:
Thu Jan 09, 2020 10:47 am


Okay, I found a bug which is BlueDV (Windows) specific. I've added a work around, do you want to test it ?

Cheers.
---
Daniel

Re: Update 9th Jan 2020

Posted: Thu Jan 09, 2020 1:08 pm
by F1RMB
Hi Mike,
KU4ZD wrote:
Thu Jan 09, 2020 1:03 pm
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

F1RMB wrote:
Thu Jan 09, 2020 10:47 am


Okay, I found a bug which is BlueDV (Windows) specific. I've added a work around, do you want to test it ?

Cheers.
---
Daniel
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

Posted: Thu Jan 09, 2020 9:39 pm
by VK3KYY
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.

Re: Update 9th Jan 2020

Posted: Thu Jan 09, 2020 10:14 pm
by SO5AJG
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

Posted: Fri Jan 10, 2020 4:15 am
by F1RMB
Hi,
SO5AJG wrote:
Thu Jan 09, 2020 10:14 pm
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.
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.

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

Posted: Fri Jan 10, 2020 4:17 am
by VK3KYY
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.