Logging output reports a fixed version of multimon-ng

[n8henrie]

What version of multimon-ng is pulsemodem using?

The logging output says it's multimon-ng 1.1.5, but it looks like this is a fixed string printed by EZAudio and MultimonHelper.

It looks like this is probably correct according to the included multimon-ng CMakeLists.txt. However, I don't see the file unixinput.m in the multimon-ng source when browsing the 1.1.5 tag.

Any ideas what happened here?

[pulsely]

Hello @n8henrie, the fixed string should be printed from the "initMultimon" method at EZMicrophone.m. It is where the the audio queue data handovered to the multimode-ng demod code.

Once the audio streams are decoded by the multimon-ng, the “stdout” is intercepted by the “decodeRFAPRS” method of APRSTextStreamDecodeManager.m, which is then parsed to the iOS UI.

The unixinput.m is the original implementation #1 to interface the multimode-ng code with iOS. It should be cleaned up with unnecessary dependency.

The “MultimonHelper.m” is the original implementation #2 that opens the CoreAudio APIs directly, but, given we need a Waveform visualizations for checking the input audio level from our Baofungs, the Multimon interface is done “as a hack” with EZMicrophone.m instead.

Speaking of which, the CoreAudio interface code should and will be contributed back to the multimon-ng.

Very sorry with the confusions caused. Have to admit many tries are attempted to get the codes all running nicely.

[n8henrie]

Thanks for such a thorough (and polite) response!

I'm not sure if I asked my question / voiced my concern correctly though.

Currently, the logging output reports multimon-ng 1.1.5. Is this the correct version?

For example, if you were to update to the newest release, as written the logging would still report 1.1.5 (unless you remembered to manually update this fixed string).

I'm excited to see the app is back up and running on iOS 13.1. I hope to be able to contribute back to the project as I learn more about ham radio and swift. Thank you!

[pulsely]

Hi @n8henrie.

Didn't see new APRS related changes on 1.1.6 to 1.1.8, yet, but it would not hurt to update to the latest multimon-ng. Expect new builds to be updated to the latest version as much as we can.

Also, exploring the possibilities to integrate Direwolf code as a second APRS decode engine. Always want to compare the RF decode performances of them.

[n8henrie]

I would be interested in comparing decode performance with direwolf. Currently I'm using direwolf to generate an APRS signal on a Raspberry Pi Zero, which I'm hoping to feed to a UV-5R for a high-altitude balloon project, decoding the APRS on my iPhone using another Baofeng and PulseModemA. In order to debug, I'm currently feeding the direwolf output directly to PulseModemA via a stereo cable (no radios involved), but at best only a small percentage of the packets are successfully decoded (and if the volume settings are off then none). It would be interesting to see whether decoding via direwolf's algorithm would be more successful.