APRS Receive Compatibility with other ADC Based Functions

[va7ta]

Greetings,

I wish to emphasize that I am pleased with LibAPRS.

However I ran across a compatibility issue with other ADC based functions. The APRS receive would fail following the use of an alternate ADC function as it captured the ADC and did not restore the settings for APRS operation. To resolve this I assigned the AFSK_hw_init function to a unique namespace called AFSKADCINIT. This permits the calling of AFSK_hw_init from the main loop to restore the settings following the data acquisition cycle with the syntax:

AFSKADCINIT::AFSK_hw_init();

tma

[markqvist]

I agree that is a good solution. Can you create a pull request for the changes so I can merge it?

[va7ta]

I must admit I have never used the GitHub repository from a developer perspective and at this point don't know to create a pull request. I have not had occasion to look back at this project for about 4 months thus it is not very fresh in my mind now. It may be a few months before I get back to it. If you can manage to make the change without my input that would be great else let me know and I will put it in my job jar. Thanks again for LibAPRS!

[markqvist]

That's cool! Thanks for the suggestion anyways. I will implement the change myself when I work on LibAPRS next.

[va7ta]

I have got started on the Git learning curve, cloned the latest LibAPRS version, modified 6 files with my changes and made commits to my local repo. I included some descriptive info in the Basic_usage.ino example. As I do not have a clear understanding of the remote repo commands as of yet I do not have sufficient confidence to proceed further. Any recommendations? Please advise.

[va7ta]

Hello Mark, I created a fork (va7ta/LibAPRS) and pushed the 6 files I changed then created a pull from there. I think and hope it worked OK but I am shaky with this procedure. In addition to ADC sharing I added data error flags and a user setting for changing the '=' dataTypeID flag to '!' . This is needed to be able to comply with the APRS protocol for applications were the messaging option is not implemented.

[r4d10n]

Hello Mark and Tom,

I am also facing a similar issue, since I am sampling from a current sensor using ADC in Port K (I am using williamhemmingsen/LibAPRS port for AtMega2560). APRS RX is using ADC in Port F, hence shouldn't be interfering with each other.

When doing sampling without APRS_Init(), values seem to come along fine. As soon as I do APRS_Init(), the values get corrupted every few samples.

Is there any init being done that effects the whole ADC configuration ?