defragster
Senior Member+
Cool, I wondered what TelephoneBill was looking at to get that that frequency.
There would be jitter from each interrupt to consider with more of them with the system already busy with IMU[int + i2c] + GPS_Serial. Not sure where the break even would be for improvement over the single 1 Hz and the added interrupts that would come with it and any overhead to keep the clock moving forward?
With a 1 second PPS from GPS it was better over time than RTC - but RTC only varied perhaps a hundred F_CPU cycles in an hour? I did a rolling average to smooth the jitter/cusps as a new count of cycles appeared between the 1 second interrupts to preserve the integrity of timing short term measurement to measurement - which it seems would be more important than even minute to minute.
Bumping the baud rate should not hurt - will keep the GPS data completion closer to IMU readings. I didn't want to push that past 460800 - but now seeing it has been tested.
Faster GPS updates seem interesting. I used the u-Center to get 10 Hz and it just doubled the same report every other one. I assumed it was pushing the envelope of 'space math' it could do? If it actually give more updates faster I wonder if they get less or more stable or consistent given the way my house moves ... just sitting here was it 3 to 12 inches/second I saw?
Don: I think you asked about F_BUS on T_3.6 - for 180 MHz it is in this same file "...\hardware\teensy\avr\cores\teensy3\kinetis.h" - just below the 240 MHz 'overclocking' for F_BUS about line 789::
I just bumped 180 MHz teensy to 90 Mhz F_BUS - it works - I don't see it changing much, still can't take i2c to 3.4 MHz like F_CPU==240 MHz. I did try 2.4 MHz and that works at both 60 and 90 F_BUS - bumps free Loop# passes about 4K.
There would be jitter from each interrupt to consider with more of them with the system already busy with IMU[int + i2c] + GPS_Serial. Not sure where the break even would be for improvement over the single 1 Hz and the added interrupts that would come with it and any overhead to keep the clock moving forward?
With a 1 second PPS from GPS it was better over time than RTC - but RTC only varied perhaps a hundred F_CPU cycles in an hour? I did a rolling average to smooth the jitter/cusps as a new count of cycles appeared between the 1 second interrupts to preserve the integrity of timing short term measurement to measurement - which it seems would be more important than even minute to minute.
Bumping the baud rate should not hurt - will keep the GPS data completion closer to IMU readings. I didn't want to push that past 460800 - but now seeing it has been tested.
Faster GPS updates seem interesting. I used the u-Center to get 10 Hz and it just doubled the same report every other one. I assumed it was pushing the envelope of 'space math' it could do? If it actually give more updates faster I wonder if they get less or more stable or consistent given the way my house moves ... just sitting here was it 3 to 12 inches/second I saw?
Don: I think you asked about F_BUS on T_3.6 - for 180 MHz it is in this same file "...\hardware\teensy\avr\cores\teensy3\kinetis.h" - just below the 240 MHz 'overclocking' for F_BUS about line 789::
Code:
#elif (F_CPU == 180000000)
#define F_PLL 180000000
#ifndef F_BUS
// #define F_BUS 60000000
#define F_BUS 90000000
I just bumped 180 MHz teensy to 90 Mhz F_BUS - it works - I don't see it changing much, still can't take i2c to 3.4 MHz like F_CPU==240 MHz. I did try 2.4 MHz and that works at both 60 and 90 F_BUS - bumps free Loop# passes about 4K.