ytai / ioio

Software, firmware and hardware of the IOIO - I/O for Android
Apache License 2.0
747 stars 355 forks source link

PulseInput returns incorrect frequency when no pulse is returned. #70

Open edarn opened 10 years ago

edarn commented 10 years ago

Dear Ytai!

Many thanks for creating IOIO, Some 6 years ago I built a weatherstation based on the Cinterion TV65 device, but it was horrible unstable so the IOIO will now be used for my next revision of www.surfvind.se.

However when experimenting with the pulseInput api it appears to me as if the getFrequency returns bogus data when no pulses at all are received.

I use: pulseCounter = ioio.openPulseInput(spec, ClockRate.RATE_62KHz, PulseMode.FREQ, true); freq = pulseCounter.getFrequency();

First of all, as getFrequency blocks while waiting for pulses, this means that this call blocks a very long time if no pulses arrive. (I have an anemometer connected to this pulsecounter, and if no wind = no pulses). At some point getFrequency returns, and it then returns an incorrect freq.

While debugging IncapImpl.java I see that dataReceived is called with either data[0] = 0 or data[0] = 1. ByteArrayToLong is then called and at the end of this function we see the following lines:

if (result == 0) { result = 1 << (size * 8); }

For data[0] = 0 this results in lastDuration beeing set to 256, 65536 etc which ends up giving a frequency that is incorrect. I have not yet figured out why ByteArrayToLong does this at the end, am I missing any part?

Second issue is that the data[0] = 1 when in fact there is no pulses at all received.

I´m using version 4.00 of the App library.

Kind Regards Thomas Hermansson TNA Software AB Sweden

ytai commented 10 years ago

I don't remember off the top of my head why this logic is there (i.e. 0 being considered the longest period), and it might as well be wrong, but I don't think this would fix your problem. Chances are that your input signal is noisy, causing you to get bogus pulses. The blocking behaviour is intentional. If you want to time out, you can use a TimerTask to interrupt you. See the forum for more details - this is a recurring question.

On Sat, Nov 2, 2013 at 1:40 PM, Thomas Hermansson notifications@github.comwrote:

Dear Ytai!

Many thanks for creating IOIO, Some 6 years ago I built a weatherstation based on the Cinterion TV65 device, but it was horrible unstable so the IOIO will now be used for my next revision of www.surfvind.se.

However when experimenting with the pulseInput api it appears to me as if the getFrequency returns bogus data when no pulses at all are received.

I use: pulseCounter = ioio.openPulseInput(spec, ClockRate.RATE_62KHz, PulseMode.FREQ, true); freq = pulseCounter.getFrequency();

First of all, as getFrequency blocks while waiting for pulses, this means that this call blocks a very long time if no pulses arrive. (I have an anemometer connected to this pulsecounter, and if no wind = no pulses). At some point getFrequency returns, and it then returns an incorrect freq.

While looking in IncapImpl.java I see that dataReceived is called with all data array =0. ByteArrayToLong is then called and at the end of this function we see the following lines:

if (result == 0) { result = 1 << (size * 8); }

This results in lastDuration beeing set to 256, 65536 etc which ends up giving a frequency that is incorrect.

I have not yet figured out why ByteArrayToLong does this at the end, am I missing any part?

Kind Regards Thomas Hermansson TNA Software AB Sweden

— Reply to this email directly or view it on GitHubhttps://github.com/ytai/ioio/issues/70 .

edarn commented 10 years ago

Hi Ytai!

There is unfortunately no noice on the input. I have measured it with my Rigol 20MHz oscilloscope and the signal shows only small noice between 3.3-3.2Volt. I've run it for a long time with a trigger at around 1.5V without any hit. So I think that part can be ruled out.

The blocking part is not an issue, just abit annoying. :-)

But it is abit strange that datareceived sometimes returns 1. I will debug this abit more once I get the time, but I became a father yesterday, so chances are that my spare time gets reduced. ;-)

//Thomas Den 3 nov 2013 00:12 skrev "Ytai Ben-Tsvi" notifications@github.com:

I don't remember off the top of my head why this logic is there (i.e. 0 being considered the longest period), and it might as well be wrong, but I don't think this would fix your problem. Chances are that your input signal is noisy, causing you to get bogus pulses. The blocking behaviour is intentional. If you want to time out, you can use a TimerTask to interrupt you. See the forum for more details - this is a recurring question.

On Sat, Nov 2, 2013 at 1:40 PM, Thomas Hermansson notifications@github.comwrote:

Dear Ytai!

Many thanks for creating IOIO, Some 6 years ago I built a weatherstation based on the Cinterion TV65 device, but it was horrible unstable so the IOIO will now be used for my next revision of www.surfvind.se.

However when experimenting with the pulseInput api it appears to me as if the getFrequency returns bogus data when no pulses at all are received.

I use: pulseCounter = ioio.openPulseInput(spec, ClockRate.RATE_62KHz, PulseMode.FREQ, true); freq = pulseCounter.getFrequency();

First of all, as getFrequency blocks while waiting for pulses, this means that this call blocks a very long time if no pulses arrive. (I have an anemometer connected to this pulsecounter, and if no wind = no pulses). At some point getFrequency returns, and it then returns an incorrect freq.

While looking in IncapImpl.java I see that dataReceived is called with all data array =0. ByteArrayToLong is then called and at the end of this function we see the following lines:

if (result == 0) { result = 1 << (size * 8); }

This results in lastDuration beeing set to 256, 65536 etc which ends up giving a frequency that is incorrect.

I have not yet figured out why ByteArrayToLong does this at the end, am I missing any part?

Kind Regards Thomas Hermansson TNA Software AB Sweden

— Reply to this email directly or view it on GitHub< https://github.com/ytai/ioio/issues/70> .

— Reply to this email directly or view it on GitHubhttps://github.com/ytai/ioio/issues/70#issuecomment-27634868 .