GPT Jitter

[A319]

Hi,

In my code I have a really time critical application. It's a timer which modulates a transmitter, so I have to take care about the baud rate. But since I run different threads, the timer gets a jitter. I can watch the callback jittering on my oscilloscope. The modulation sounds awful. I know I can lock the kernel by chSysLock and chSysUnlock but it unfortunately locks the GPT too. I thought the GPT is hardware controlled, isn't it?!?

Regards
Sven

[Giovanni]

Hi Sven,

You could place the GPT IRQ priority at level zero, this would not be delayed by kernel critical zones. However:

1) The GPT ISR calls the OS, you have to exclude it and write your own (by defining STM32_TIMx_SUPPRESS_ISR). Fast ISRs are declared using CH_FAST_IRQ_HANDLER.
2) You cannot call OS functions from fast ISRs. You can use SVPEND to delegate OS calls to a lower priority ISR.

This would ensure minimal jitter depending on IRS code, it could be as low as 12 clock cycles (Cortex-M late arrival mechanism).

Giovanni

[A319]

Hi Giovanni,

Thank's for your quick answer. I've tried to set the GPT IRQ priority to zero. but the highest priority I have been able to set, is two (mcuconfig.h)

Code: Select all

#define STM32_GPT_TIM1_IRQ_PRIORITY         0

Code: Select all

In file included from ChibiOS//os/hal/include/gpt.h:69:0,
                 from ChibiOS//os/hal/include/hal.h:51,
                 from ChibiOS//os/hal/src/hal.c:25:
ChibiOS//os/hal/ports/STM32/LLD/TIMv1/gpt_lld.h:398:2: error: #error "Invalid IRQ priority assigned to TIM1"
 #error "Invalid IRQ priority assigned to TIM1"

I think that other threads are the problem which are active at the same time. The interrupt won't occur at the specific time, while another thread is already running.
I have bad experiences mixing ChibiOS and STDPeriph. I always had problems with name conflicts or missing various macros. But I will try this in the next days. 12 clock cycles is more than enough.

Sven

[barthess]

@A319
Did you think about combining timer and DMA? This will be totally hardware solution.
Any way, there are not enough details about your project to do meaningful suggestions.

[Giovanni]

Hi,

I will add an option to disable checks in next version. In the meanwhile you can change the ISR priority after starting the driver.

Giovanni

[A319]

Hi,

@Giovanni Thank's. I will try this.
@barthess not yet. I had a private repository which I made now public. It's all about a balloon tracker (or some also say tiny amateur satellite).

My newest version (Pecan Pico 7) is able to capture images and transmit them by amateur radio APRS (Automatic Packet Reporting System).
To archive the APRS's AFSK modulation (it's FSK [frequency shift keying] on FM) I have to audio modulate the transmitter by the STM32F4. And this has to be done accurately otherwise the modulation sound awful and the receive wont decode.
In the past I've modulated the main oscillator with a PWM and a RC low pass filter (like it's done on the RaspberryPI Audio Output). However I found out, how to hack the transmitter, so I can do now everything in software. Instead of feeding the the modulation to the oscillator, I send the audio (in square wave) directly into the transmitter (Si4464). The transmitter does 2GFSK square wave (so almost like FM). The square wave is then filtered by a FIR-Filter (inside the Si4464). The final product is a FM-modulation on which you will find 2 frequencies (bit 0 and 1). And if the timing is not accurate enough, the receiver wont decode

Short info about the project: This a picture of the balloon tracker
https://drive.google.com/file/d/0BwzVllHCGu5FWFpxbHFTZ1BSMTA/view?usp=sharing
Our goal is it, to build a tracker which can track it's position and transmit pictures on a single board to the ground. (@Giovanni and that's the reason why I made the DCMI evaluation back in day ). It has to be light (<25g with chargeable battery)
The tracker also has low power capabilities. So it consumes less than 100mA when transmitting images. In sleep the current may be reduced to less than 10...5mA. We will charge the batteries again by solar cells because the tracker will fly on a long duration balloon. It may survive several day/weeks (maybe even months).

Here are the software source files.
https://github.com/DL7AD/pecan-stm32f429
modules/radio.c - does the modulation. You will find the timer for the AFSK there (look for GPTConfig gptcfg_afsk)
drivers/si4464.c - Transmitter driver (configures FIR-Filter)

Here are the hardware source files. I currently have the revision 7a but I'm currently planning 7b. 7a has a lot of errors unfortunately.
https://github.com/DL7AD/pecanpico7
PCB: https://drive.google.com/file/d/0BwzVll ... sp=sharing
Front: https://drive.google.com/file/d/0BwzVll ... sp=sharing
Back: https://drive.google.com/file/d/0BwzVll ... sp=sharing
Testing buildup: https://drive.google.com/file/d/0BwzVll ... sp=sharing
Transmitted test pictures: https://drive.google.com/folderview?id= ... sp=sharing
How we produce the PCBs (reflow): https://drive.google.com/folderview?id= ... sp=sharing (we "bake" them on a crepe plate)

Regards
Sven

[Giovanni]

hi,

You could use the PWM driver and change the width/frequency from the periodic callback. The change has effect on the next cycle so it would be relatively immune from jitter.

Giovanni

[jscott]

That kind of what I was thinking also.
Any jitter that you would have not be a problem. It would be a very small fraction of the 1200 baud signal.

1200 BAUD should be Real Easy on resources for this processor. But I am wondering if there is more to this then meets the eye. He is calling the callback WAY FAST!



-John

[jscott]

Hi Sven,

I have a couple of questions about your modulator callback.

It looks like you are sending data at 1200 BAUD to two samples per BAUD. Correct?

You are configuring the GPT to clock at 180,000,000 Hz (180MHz).
You are calling your callback at 720,000 Hz.

Do you really mean to call your callback at 720,000 Hz.
This is 300 times per sample or 600 times per baud!

This seems very high to me.

-John Scott - kd4vhg

[A319]

Hi,

PWM sounds great I like that idea.

The very high frequency is just a workaround I found out, there will be no other threads executed if the ISR fills up all clock cycles So I have no jitter. No great solution though.

Regards
Sven (DL7AD/AF5LI)