[pskmail] Re: Andpskmail

  • From: John Douyere <vk2eta@xxxxxxxxx>
  • To: pskmail@xxxxxxxxxxxxx
  • Date: Thu, 22 Dec 2011 12:14:57 +1100

Hi Greg,

Appreciate the feedback.

1. You are correct, the mode change is an automatic feature, driven by the
server, and the downgrade or upgrade of modes is linked to two things:

A. The absence of replies from the client: after two non-replies on the
same mode  the server starts alternating the downgrades of the Rx and TX
modes.

B. The received quality of the signal as reported by Fldigi (after a <EOT>
character is received) for the receive side and for the TX side the signal
quality reported by the client.


If you want to reduce the hunting down that occurs: if you are using the
microphone, I would suggest you use a smaller list of modes and concentrate
on the MFSK or THOR modes that more robust (but slower). I would also avoid
the very slow modes so that the system does not have to re-learn the
fastest mode after a couple of missed replies from the client.

I would try a list like MFSK32, THO22 and THOR11 for example. This should
give you a more robust link in this particular case as the PSK modes
require better audio quality than the frequency shifting ones.

Interesting point about this happening while switching to the modem screen.
Can you check this again as I haven't noticed that. I will try to reproduce
on my side too.

On top of the one I have already described in the manual, I have just
completed a new Bluetooth interface using a small "ear-worn" headset and
that works really well and can be built very small. It make a significant
difference in signal quality especially on the client's RX side and I would
recommend such an interface for connected sessions.

I will publish the "design" (4 resistances and one capacitor) as soon as I
can. Overall project cost is about $14.

2. The disconnect issue, first thing to check: does the modem screen show
that the ~QUIT command has been sent (the next *TX* line after pressing the
disconnect button)? If not I suspect it is related to the client not
hearing the server properly, in which case an abort is ok (although not the
easiest option).

3. I haven't looked at the force close reports yet but I will and I'll let
you know. Did you get force closes on the application?

Great work. Also, can you tell me more about the intended usage of the
application.

Thanks and 73, John (VK2ETA)



On Thu, Dec 22, 2011 at 4:45 AM, Greg <kb1ncj@xxxxxxxxx> wrote:

> Hi John
>
> Thanks for the reply. I was able to send through another server so I
> assume it was the server side smtp configuration.
>
> As far as the android app, I have a few observations...
> The mode sometimes changes and I think it requests different modes via
> rsid. Maybe this is automatic because of poor receive. I am using the built
> in mike for now so it doesn't decode 100% every time. It seems to only
> happen when I switch to the "modem" screen. It looked like it switch to
> every mode in the list after that. I did get a few force closes too. I am
> using motorola mb200 with cyanogen custom rom, gingerbread.
>
> Also the disconnect command says it will send a disconnect command but it
> never does. The only way I have been able to stop the session is the abort
> option.
>
> Will the option to report the force close go to the right place or does it
> just go to google or rom maker?
>
> Thanks again and good holiday
> Greg

Other related posts: