Sampling rate of a PIC. Please Help!

[Nigel Goodwin]

Probably not as bad as most people would think!

No, like I said above - for MANY years the British telephone service (probably still the Post Office back then?) ran a VERY successful service where you could ring in and listen to current chart hits. This was back in the days of carbon microphones and the crude earpieces in phones, today's modern phones would sound even 'better'.

SSB amateur radio is perfectly understandable, yet only uses a much lower bandwidth than phones.

 

[3v0]

Mr T.

We want to sample at 8KHz and do not need to bother with the ADC interrupt. Seriously if you can do it easier with a special event trigger I want to see it as I have not used them.

TIMER ISR:
  READ CONVERTED VALUE
  RELOAD TIMER IF NOT DONE BY THE HARDWARE
  START CONVERSION
  SET XFLAG IF WE HAVE ENOUGH DATA FOR A PACKET
  RTI

MAIN:
  SETUP HARDWARE
  REPEAT
      IF (XFLAG) SEND PACKET
      CLEAR XFLAG

john_19
Are you getting the correct audio on the other side of the internet link it you string together the packets without a delay between them. Like save a 100 packets then play them.

The one thing that bothers me is the interaction between the above code and the stack. I am not sure what the stack uses for interrupts. But it might be possible to make the TIMER interrupt a high priority and any stack interrupts low priority. The idea is it lets you continue collecting data during the packet transmission. For this to work you need to keep the TIMER ISR short as possible.

Good luck and keep us posted.

 

[misterT]

Mr T.

We want to sample at 8KHz and do not need to bother with the ADC interrupt. Seriously if you can do it easier with a special event trigger I want to see it as I have not used them.

Why bother with timer interrupt when we can do it all with ADC interrupt.

ADC ISR:
  READ CONVERTED VALUE
  SET XFLAG IF WE HAVE ENOUGH DATA FOR A PACKET
  RTI

MAIN:
  SETUP HARDWARE
  REPEAT
      IF (XFLAG) SEND PACKET
      CLEAR XFLAG

I have not used PICs for a long time, but I can read the datasheet. I am pretty sure that setting up the event trigger for ADC is quite trivial. And for some reason using the ADC interrupt with the ADC feels just natural.. go figure.

 

[Nigel Goodwin]

Why bother with timer interrupt when we can do it all with ADC interrupt.

I've not made any suggestions either way - but presumably using a timer interrupt automatically sets your sampling rate, using an ADC interrupt merely tells you when the conversion is finished, and you still have to accurately time when you want the conversion to begin to provide your required sampling rate. So using a timer interrupt does everything in one simple interrupt. whereas using the ADC interrupt means you need at least double the amount of work.

 

[john_19]

Mr T.

We want to sample at 8KHz and do not need to bother with the ADC interrupt. Seriously if you can do it easier with a special event trigger I want to see it as I have not used them.

TIMER ISR:
  READ CONVERTED VALUE
  RELOAD TIMER IF NOT DONE BY THE HARDWARE
  START CONVERSION
  SET XFLAG IF WE HAVE ENOUGH DATA FOR A PACKET
  RTI

MAIN:
  SETUP HARDWARE
  REPEAT
      IF (XFLAG) SEND PACKET
      CLEAR XFLAG

john_19
Are you getting the correct audio on the other side of the internet link it you string together the packets without a delay between them. Like save a 100 packets then play them.

The one thing that bothers me is the interaction between the above code and the stack. I am not sure what the stack uses for interrupts. But it might be possible to make the TIMER interrupt a high priority and any stack interrupts low priority. The idea is it lets you continue collecting data during the packet transmission. For this to work you need to keep the TIMER ISR short as possible.

Good luck and keep us posted.

Hi 3v0, well after a few tests what I can tell you is that I'm getting the audio, but the level of the signal is really low plus I have same noise. At the moment the ISR is in low priority. What I found is that it's taking almost 4ms to the ENC to send the packet (honestly I thought it was going to be faster) but the ADC keeps sampling so I guess I'm losing samples.
Based on the above I used 2 buffers so at the time one is ready and it's been sent the ADC saves samples in the other one. Plus I was reading that if you the checksum for the UDP you lose 50% of performance so I disabled the checksum.
When I tested the board with this changes and checked the time between packets with the wireshark I got between 21 and 22ms (160 bytes all of them) but there was no audio at all. I didn't save the capture I did with wireshark but I what I saw on it was that the packets have the IP source address but not the MAC address and on top of that it changed the PORT where the packets are sent from the one I programed to zero.
I guess it doesn't like the checksum disabled. I'll go and double check the lines of code related with the checksum. If you have the option to use it or not, it shouldn't affect the MAC address, right??
I'll keep you posted.
If I wasn't clear please let me know, my english level is not that good.
Regards.-

 

[misterT]

timer interrupt automatically sets your sampling rate
...
whereas using the ADC interrupt means you need at least double the amount of work.

No no no.. Event trigger (Timer1 with CCP2) automatically sets your sampling rate. ADC interrupt is used to read the conversion result. Using timer interrupt (to read and trigger the ADC) doubles the amount of work. Also, using timer interrupt leads to timing problems (unconstant sampling rate and latency).. it sounds backwards, but that is the case.

 

[Nigel Goodwin]

No no no.. Event trigger (Timer1 with CCP2) automatically sets your sampling rate. ADC interrupt is used to read the conversion result. Using timer interrupt (to read and trigger the ADC) doubles the amount of work. Also, using timer interrupt leads to timing problems (unconstant sampling rate and latency).. it sounds backwards, but that is the case.

Sorry, but I don't agree - and don't see your reasoning?.

The timer interrupt simply reads the already existing ADC value, then triggers the ADC for the next reading, and then exits leaving the ADC to 'get on with it'.

BTW, how's the weather in Finland?, my daughter is in Helsinki this week (Thursday to Thursday). She went to Suomenlinna on Friday, and really enjoyed it - from what I can gather from occasional one line emails

 

[misterT]

The timer interrupt simply reads the already existing ADC value, then triggers the ADC for the next reading, and then exits leaving the ADC to 'get on with it'.

ADC interrupt simply reads the conversion result immediately after the conversion is completed. No need to manually trigger the ADC for next reading. If you use timer interrupt to read and trigger the ADC, the information is always "old". Also, if the interrupt is delayed for some reason (another ISR is blocking it) then you get errors in the sampling rate. Better use the event trigger that keeps the ADC going in background.

Weather here (Helsinki) is exceptionally good. Usually it gets cold and rainy this time of year, but for some reason the summer is going strong

 

[Nigel Goodwin]

ADC interrupt simply reads the conversion result immediately after the conversion is completed. No need to manually trigger the ADC for next reading. If you use timer interrupt to read and trigger the ADC, the information is always "old".

Only 'old' by one sample time, in this case 125uS - no concern whatsoever for simple audio sampling - even your method is old' as well, by the settling time, acquisition time and interrupt latency.

Also, if the interrupt is delayed for some reason (another ISR is blocking it) then you get errors in the sampling rate. Better use the event trigger that keeps the ADC going in background.

But in your method you have two interrupts that could be blocked , only one if you use just a timer interrupt.

Weather here (Helsinki) is exceptionally good. Usually it gets cold and rainy this time of year, but for some reason the summer is going strong

So that's where OUR Summer went - the Finn's stole it!

Her boyfriend is attending Helsinki University for a year (for the fourth year of his masters degree in Chemistry), and he got sun burnt in his first week (two weeks ago). My daughter is doing a research year in Industry in the Netherlands, but doesn't start until 4th September - which coincidently is her birthday.

BTW, she's not happy about the price of beer in Helsinki!

 

[3v0]

I am far more concerned about the interaction between the timer ISR used to sample and the internet stack.

 

[john_19]

Hi guys!, just in case I enabled the checksum again and I'm getting the same time (around 22ms) and Wireshark's still displaying the MAC 0.0.0.0 and PORT 0. I don't know what to think right now, I just changed from using one buffer to two buffers.
I guess it won't hurt if try using the event trigger.
Regards.-

 

[Nigel Goodwin]

You can certainly try it - but I doubt it will make any difference - I'm with 3V0 and suspect your problems are more to do with Ethernet than sampling.

You really need to separate the two functions, and make sure both work independently for a start.

 

[3v0]

What Nigel said.

If you turn off (comment out, strip out) the Ethernet and toggle a port bit each time you have a full buffer you can figure out if the problem is with the ADC. If every buffer has 20ms of data and you see the pin toggle every 20ms you know you have the ADC working right. Figure this out prior to burning time on something that is already working.

It may be easier to use one PIC to do the sampling and use SIP or parallel to transfer data to a 2nd running the Ethernet stack.

 

[misterT]

But in your method you have two interrupts that could be blocked , only one if you use just a timer interrupt.

There is only one interrupt the "ADC interrupt" that comes when the conversion is done. The "Special Event Trigger" works in the background and keeps a constant sampling rate. Check out page 268 of the datasheet: https://www.electro-tech-online.com/custompdfs/2012/08/39632d.pdf

"An A/D conversion can be started by the Special Event
Trigger of the CCP2 module. This requires that the
CCP2M3:CCP2M0 bits (CCP2CON<3:0>) be programmed
as ‘1011’ and that the A/D module is enabled
(ADON bit is set). When the trigger occurs, the
GO/DONE bit will be set, starting the A/D acquisition
and conversion and the Timer1 (or Timer3) counter will
be reset to zero. Timer1 (or Timer3) is reset to automatically
repeat the A/D acquisition period with minimal
software overhead"

 

[Nigel Goodwin]

There is only one interrupt the "ADC interrupt" that comes when the conversion is done. The "Special Event Trigger" works in the background and keeps a constant sampling rate. Check out page 268 of the datasheet: https://www.electro-tech-online.com/custompdfs/2012/08/39632d.pdf

Cool - I wasn't aware of that

Although I don't see as it makes much real difference, apart from removing the 125uS delay and removing a couple of instructions from the ISR - but of course ISR's are best kept as short as possible, so perhaps worth it for saving a few words.

 

[3v0]

MisterT do you really think this will help the original poster. The special trigger thing is interesting but there is a lot of setup and you still have to add the H and L ADC results and save them to the buffer etc.

 

[misterT]

MisterT do you really think this will help the original poster. The special trigger thing is interesting but there is a lot of setup and you still have to add the H and L ADC results and save them to the buffer etc.

The topic is about sampling rate. I know rambling about the same thing for pages does not help, but I can't let wrong info go through if I know I'm right. I don't understand why "there is a lot of setup" is a problem.. and at the end there really is not that much setup to do. I took the time to study the datasheet so I can give good answers to the problem and then you start arguing against perfectly good solution without studying things yourself.

I think you arguing against me is more useless than me trying to tell how the ADC is used properly.

 

[3v0]

I was trying to help the OP get his code working.
The instructions I gave him to do the sampling is valid, it works.
The problem he is having is most apt to be with the internet stack interaction.
Both Nigel and I suggested he isolate the code and check it.

I am not here to argue or fight.

 

[john_19]

Hi guy!!. Well, after a few days I'm getting the packets with a time difference between them close to the one I want.
Still have to work things out about the noise I'm getting.
Regards.-

 

[3v0]

Spread the wealth and let us know what you had to change to make it work ?