Smart SDR Griffin PowerMate PTT latency.

Andy M5ZAP

Hi,

I have just purchased a BT Griffin PowerMate, as for me one of the biggest downsides of SmartSDR iOS was the ability to easily and quickly fine tune and the need to use the PTT on screen if VOX wasn't used (I don't get on with VOX).

The tuning seems to work quite well but I find the latency for the PTT to be far too great to be usable. Does anybody else have experience with the Bluetooth Griffin PowerMate and SmartSdr iOS.

Also once the device is connected I can go back to the griffin setup screen within SSDR iOS and it often says "Connecting" rather than "Connected" but appears to be working OK.

Any help or comments gratefully received, before I decide if I will send the Griffin PM back.

Andy M5ZAP

DV

There will be a latency whenever bluetooth is used. I have also acquired the "wheel", and for my work the latency is not very noticable nor bothersome, however in a contest it could be an issue.  I find even more latency when using a bluetooth and a blue tooth headset.

Andy M5ZAP

Hi looking at the Bluetooth spec the latency should be more than acceptable and there doesn't appear to be any latency on the LED when using iPad PTT.

Marcus - Do you have any comment on the expected latency?

Also if you map the button to PTT Push then it doesn't work and the pressing of the griffin simply latches PTT on and you have to release PTT by pressing PTT on the iPad.

It appears that the PTT toggle is triggering off the bush button release rather than the push button make as the delay seems to be consistent from the release not the press. This doesn't help the latency feel. (If you hold the press more than approx 1 sec it is ignored)

Checking the Powermate with its native app under OSX there is also no noticeable latency with a button press action.

ThisUserDoesNotExist

I will look into that. Most likely, I and not BT is responsible at least for parts of the latency as I implemented some kind of 'debouncing' to the Griffin. That was mostly because of the wheel as, from my experience, often sends forward and backward spinning information while it was just turned forwards (or the other way round). But while this seem to work well for the wheel it might be disadvantageous for the switch.

But probably, if you say OSX behaves similar, it might be that they follow the same approach.

Again, I will look into that and see what I can do.

The reason why holding for more than one sec works different is, that the Griffin generates another code for this gesture. It also generates additional codes while holding down even longer. You can see this in the Map Editor. Also, there are different codes for holding down and spinning. First I though I should ignore these additional codes as I didn't found them useful to be able to get assigned with additional functions but Beta Testers convinced me to leave them in.

vy 73,
Marcus, DL8MRE

Andy M5ZAP

Thanks Marcus You slightly misunderstood part of my post. Under OS X there is no latency when I tested using the griffin app.

ThisUserDoesNotExist

Hi again Andy,

and now, regarding the Griffin.

I was able to optimize the Latency a bit but, if you try yourself, you will find that the OS X Version has exactly the problem I was talking about. For instance, if you use the button to mute/unmute volume on OS X. It sometimes toggles immediately back and sometimes it works. The Griffin sometimes generates more than one "key-press" shortly after another. This was, why I added some software de-bouncing to the button. The de-bouncing was using a 300ms delay which was probably a bit too 'conservative'. A 100ms delay was too quick. With this, in several tests, I ran into the issue that the button was reported as pressed twice which wasn't the case. A value of 200ms seem to give the best results.

In the next update, I am using this value of 200ms.

73,
Marcus

Andy M5ZAP

Thanks Marcus I look forward to trying the griffin with the 200mS value. Could you possibly implement the iPad Pro keyboard for tuning and PTT?