uNav INS

Tim,

The last couple of hours I've been exploring tuning some of the R and Q parameters, just to try and get a first order cut at tuning. The new plots on TViewer are awesome for this.

Here's my latest versions. They're the same as my last post, except for some tweaks (as commented in the code) to some of the noise parameters.

View attachment TVslaveDKV4.zip
View attachment uNavINS_CB_Ver4.zip
View attachment TV_Layout_CFVer8.txt

I'm going to take a break from the screen, need to run errands and such. I did not get to switching the output back to doubles yet, or increasing the SPI buffer to 400.
 
Got it ... will FIX SPI_MST buffers and go back to double first

<edit1>
The changes to SPI_MSTransfer are about line #44 - this will cause it to consume 12,800 bytes of RAM on MASTER and SLAVE - but allow transfer of 100 doubles:
Code: 
#define DATA_BUFFER_MAX 400
#define QUEUE_SLOTS 8
>> I did not pull the latest SPI_MSTransfer from github - in case changes for i2c cause grief :confused:
>> Could probably use just 4 queue_slots for half that RAM - maybe that would be a case for #ifdef T_3.1 where RAM is smaller?


<edit2>
Seems to be working. Had to pull circular_buffer from github to get .mean.
Here is zip of Master serialPrint and DKslave files as updated to handle Doubles::
View attachment DOUBLEDCB_Ver4.zip
Click to expand...

Code: 
  0.025893, 41.981422, 64.203186, 56.487690,268.831848, 48.214367,-122.450302, 54.356213, -0.002948, -0.002948,  0.000000, -0.000000,  1.000000, -1.000000,  0.002937,  0.002937,  0.000000, -0.000000,  1.000000, -1.000000, -0.000289, -0.000289,  0.000000, -0.000000,  3.000000, -3.000000,  0.110292,  0.110292,  0.000000, -0.000000,  0.050000, -0.050000,  0.092318,  0.092318,  0.000000, -0.000000,  0.050000, -0.050000, -0.246292, -0.246292,  0.000000, -0.000000,  0.050000, -0.050000,  0.189510,  0.189510,  0.000000, -0.000000,  0.020000, -0.020000,  0.542981,  0.542981,  0.000000, -0.000000,  0.020000, -0.020000, -1.255967, -1.255967,  0.000000, -0.000000,  0.020000, -0.020000,  0.995037,  0.995037,  2.873479,  0.049940,  0.049940,  0.049939,  0.247798,  0.242327,  0.263458,  0.980703,  0.980702,  0.980702,  0.017446,  0.017446,  0.017446,
  0.245637, 57.296444,101.851028, 97.817528,310.161713, 48.214375,-122.450302, 54.371513,  1.736589,  0.866821,  0.869768, -0.869768,  1.000000, -1.000000,  0.398070,  0.200503,  0.197567, -0.197567,  1.000000, -1.000000, -0.239297, -0.119793,  0.119504, -0.119504,  3.000000, -3.000000,  1.280656,  0.695474,  0.585182, -0.585182,  0.050000, -0.050000,  1.541695,  0.817006,  0.724688, -0.724688,  0.050000, -0.050000, -2.154730, -1.200511,  0.954219, -0.954219,  0.050000, -0.050000,  0.161722,  0.175616,  0.013894, -0.013894,  0.020000, -0.020000, -0.127318,  0.207831,  0.335150, -0.335150,  0.020000, -0.020000, -0.594141, -0.925054,  0.330913, -0.330913,  0.020000, -0.020000,  0.705509,  0.705509,  2.075203,  0.049830,  0.049849,  0.049820,  0.101555,  0.098923,  0.108305,  0.940741,  0.897735,  0.910019,  0.017332,  0.017330,  0.017336,
  0.445405, 51.884926,114.334541,111.759560,324.103729, 48.214378,-122.450302, 54.399788,  0.834592,  0.856078,  0.710325, -0.710325,  1.000000, -1.000000,  0.237638,  0.212881,  0.162259, -0.162259,  1.000000, -1.000000, -0.147978, -0.129188,  0.098475, -0.098475,  3.000000, -3.000000,  0.800187,  0.730378,  0.480342, -0.480342,  0.050000, -0.050000,  0.991482,  0.875165,  0.597395, -0.597395,  0.050000, -0.050000, -0.986878, -1.129300,  0.785598, -0.785598,  0.050000, -0.050000,  0.165591,  0.172274,  0.012290, -0.012290,  0.020000, -0.020000,  0.042513,  0.152725,  0.284529, -0.284529,  0.020000, -0.020000, -0.163358, -0.671155,  0.449368, -0.449368,  0.020000, -0.020000,  0.576756,  0.576753,  1.706769,  0.049768,  0.049740,  0.049747,  0.091770,  0.089442,  0.097877,  0.911773,  0.838089,  0.859644,  0.017184,  0.017181,  0.017195,

// ...

400.843475, 52.994671,127.535187,145.018906,357.363068, 48.214371,-122.450401, 31.547159, -0.528121, -0.088346,  0.261888, -0.261888,  1.000000, -1.000000,  0.707620,  1.058182,  0.208802, -0.208802,  1.000000, -1.000000, -4.852314, -4.996496,  0.080964, -0.080964,  3.000000, -3.000000, -0.055146,  0.003319,  0.032572, -0.032572,  0.050000, -0.050000,  0.119817,  0.075567,  0.050972, -0.050972,  0.050000, -0.050000, -0.038516, -0.025392,  0.013309, -0.013309,  0.050000, -0.050000,  0.000217, -0.000010,  0.001740, -0.001740,  0.020000, -0.020000,  0.001212,  0.000109,  0.002989, -0.002989,  0.020000, -0.020000,  0.000905,  0.000114,  0.001786, -0.001786,  0.020000, -0.020000,  0.163190,  0.164389,  0.284269,  0.049696,  0.049704,  0.049694,  0.039739,  0.038740,  0.042178,  0.085898,  0.095186,  0.090197,  0.008024,  0.008018,  0.008047,
401.043243, 52.968937,127.286713,144.561371,356.905518, 48.214371,-122.450401, 31.582771, -0.555414, -0.116829,  0.261572, -0.261572,  1.000000, -1.000000,  0.636406,  1.034552,  0.212379, -0.212379,  1.000000, -1.000000, -4.821050, -4.989933,  0.086236, -0.086236,  3.000000, -3.000000, -0.015256,  0.005285,  0.029333, -0.029333,  0.050000, -0.050000, -0.065192,  0.070087,  0.056123, -0.056123,  0.050000, -0.050000, -0.024458, -0.025049,  0.013186, -0.013186,  0.050000, -0.050000, -0.000595, -0.000041,  0.001741, -0.001741,  0.020000, -0.020000,  0.000840,  0.000047,  0.002952, -0.002952,  0.020000, -0.020000,  0.001327,  0.000086,  0.001760, -0.001760,  0.020000, -0.020000,  0.163182,  0.164380,  0.284263,  0.049696,  0.049704,  0.049694,  0.039765,  0.038774,  0.042134,  0.085898,  0.095185,  0.090197,  0.008025,  0.008018,  0.008046,
401.243011, 53.074959,127.544518,144.775421,357.119598, 48.214371,-122.450401, 31.618610, -0.570826, -0.145780,  0.258937, -0.258937,  1.000000, -1.000000,  0.631240,  1.009898,  0.211974, -0.211974,  1.000000, -1.000000, -4.811244, -4.980884,  0.089265, -0.089265,  3.000000, -3.000000,  0.056146,  0.006264,  0.030470, -0.030470,  0.050000, -0.050000,  0.087187,  0.071010,  0.056154, -0.056154,  0.050000, -0.050000, -0.035914, -0.025156,  0.013260, -0.013260,  0.050000, -0.050000, -0.001970, -0.000119,  0.001769, -0.001769,  0.020000, -0.020000, -0.003767, -0.000036,  0.003020, -0.003020,  0.020000, -0.020000, -0.001586,  0.000083,  0.001762, -0.001762,  0.020000, -0.020000,  0.163175,  0.164371,  0.284257,  0.049696,  0.049704,  0.049694,  0.039853,  0.038606,  0.042208,  0.085898,  0.095185,  0.090196,  0.008025,  0.008017,  0.008047,
401.442810, 52.976898,127.397484,144.687592,357.031769, 48.214371,-122.450401, 31.654034, -0.581213, -0.173560,  0.256463, -0.256463,  1.000000, -1.000000,  0.628227,  0.985794,  0.210141, -0.210141,  1.000000, -1.000000, -4.792989, -4.971549,  0.092739, -0.092739,  3.000000, -3.000000,  0.014710,  0.006985,  0.030388, -0.030388,  0.050000, -0.050000,  0.036253,  0.069069,  0.056248, -0.056248,  0.050000, -0.050000, -0.019425, -0.024987,  0.013298, -0.013298,  0.050000, -0.050000,  0.001763, -0.000057,  0.001799, -0.001799,  0.020000, -0.020000,  0.002890,  0.000067,  0.003061, -0.003061,  0.020000, -0.020000,  0.000987,  0.000119,  0.001768, -0.001768,  0.020000, -0.020000,  0.163168,  0.164364,  0.284251,  0.049696,  0.049704,  0.049694,  0.039768,  0.038736,  0.042172,  0.085898,  0.095184,  0.090195,  0.008025,  0.008018,  0.008047,
401.642548, 53.085239,127.515175,145.058197,357.402374, 48.214371,-122.450401, 31.689840, -0.633237, -0.202632,  0.254186, -0.254186,  1.000000, -1.000000,  0.663924,  0.962143,  0.202300, -0.202300,  1.000000, -1.000000, -4.819492, -4.962437,  0.092907, -0.092907,  3.000000, -3.000000, -0.079317,  0.003755,  0.033715, -0.033715,  0.050000, -0.050000,  0.115864,  0.068352,  0.055496, -0.055496,  0.050000, -0.050000, -0.040101, -0.025653,  0.013503, -0.013503,  0.050000, -0.050000, -0.001454, -0.000055,  0.001798, -0.001798,  0.020000, -0.020000, -0.000290,  0.000062,  0.003062, -0.003062,  0.020000, -0.020000,  0.001100,  0.000113,  0.001764, -0.001764,  0.020000, -0.020000,  0.163161,  0.164356,  0.284245,  0.049696,  0.049704,  0.049694,  0.039833,  0.038731,  0.042138,  0.085898,  0.095184,  0.090195,  0.008025,  0.008018,  0.008046,
401.842316, 53.016594,127.309227,144.982376,357.326569, 48.214371,-122.450401, 31.728170, -0.624710, -0.231199,  0.248585, -0.248585,  1.000000, -1.000000,  0.657532,  0.939070,  0.193427, -0.193427,  1.000000, -1.000000, -4.833694, -4.953070,  0.090268, -0.090268,  3.000000, -3.000000,  0.036340,  0.003251,  0.033097, -0.033097,  0.050000, -0.050000,  0.059283,  0.069146,  0.055178, -0.055178,  0.050000, -0.050000, -0.043791, -0.026254,  0.013864, -0.013864,  0.050000, -0.050000,  0.001150,  0.000013,  0.001801, -0.001801,  0.020000, -0.020000,  0.003656,  0.000260,  0.003083, -0.003083,  0.020000, -0.020000,  0.002279,  0.000230,  0.001780, -0.001780,  0.020000, -0.020000,  0.163155,  0.164350,  0.284239,  0.049696,  0.049704,  0.049694,  0.039783,  0.038886,  0.042046,  0.085898,  0.095183,  0.090195,  0.008025,  0.008019,  0.008045,

<edit3>
Quick Check of Max IMU# at 180 MHz shows slight drop at printRate 25 with current code::
-----Loop#:49011 IMU#:989

Change to SRD=1 for 500 Hz IMU with DK's printRate of 10 shows it keeping up with some breathing room::
-----Loop#:371968 IMU#:500

T_3.5 Slave seems to be having no trouble feeding TViewer.

I did one quick rotation set during a calibration - it stopped with a NaN.

Restarted and just did two direction rotation and quit moving it and it picked up okay and it running - not sure if this shows anything interesting:
TV_uNavINS_CB_Ver4.jpg

... onto punching the clock . . .
 
Last edited:
Don: Will give the new version a try tonight. Found a updated version of Telemetry Viewer (src only) on GitHub. Been talking with him on scrollbars for the chart selections. Been working on it on and off all day but I don't know enough about Java. Hopefully tomorrow.

Tim: Been working with the I2C version since tonton81 put it up on the other thread for my testing with the last version Don posted and it works just fine - changes didn't break anything and I2C does work so opens up a few more possibilities.
 
yeah the additional functions dont touch F&F's or other additions. Its great to have upgradability without worries :) only the NVIC priorities were changed to support I2C, UARTS, USBSerial at NVIC 0, while MST at 1. This was the only way to have I2C working over SPI_MST as I2C requires interrupts, and was locking up the poor little T3.5 until the NVIC was adjusted.

Now that UARTS/USBSerial were also pushed ahead to 0, perhaps USBSerial will perform better for you now :)
 
Ok. quick status. running both T3.5s at 168Mhz, 250hz IMU and printRate = 10ms and its keeping up pretty good:
-----Loop#:278138 IMU#:198

Only problem is that I am not getting anything on the Tviewer with the new layout - old or new version.
 
mjs513 said:
Ok. quick status. running both T3.5s at 168Mhz, 250hz IMU and printRate = 10ms and its keeping up pretty good:
-----Loop#:278138 IMU#:198

Only problem is that I am not getting anything on the Tviewer with the new layout - old or new version.
Click to expand...

The TViewer was working for me? The new code TV ZIP doesn't have the JAR to start it?



Looks like your IMU is at 200 not 250 hz or loops would be down? If Loop# ever nears IMU# - like my worst case capacity tests or IMU's are missed it will be bad for filtered results with missed updates

... back to looking for my old RTC code . . . so long ago ... so many updated versions . . .
 
I've begun to get started:
-----Loop#:371358 IMU#:501| IMUcc:961 GPScc:3109
#16569 @7:30.38_324195 [fix:3 #:11 GPScc:3125
#16570 @7:30.38_200324272 [fix:3 #:11 GPScc:2799
#16571 @7:30.38_400324348 [fix:3 #:11 GPScc:2199
#16572 @7:30.38_600324424 [fix:3 #:10 GPScc:3089
#16573 @7:30.38_800324500 [fix:3 #:10 GPScc:2273
Click to expand...

The SerialRx_isr is recording the CycleCount at time of isr() - and printing above as GPScc:## that is the Micros elapsed to completion. The variation there should be showing the lag between Rx Start and ending the prior loop() to get back to see the GPS string completed. IMUcc:## is similar - time since the last IMU_isr() recorded - an printed when GPS record is complete.

Seeing the numbers in use has changed idea on PartSec - isr()'s record the CCount on entry [GPS & IMU]. Need to figure out where to go from there, seems I need a version to take two CycleCounts to diff and return as Part_of_Sec for 'dt'.

'cc' Numbers above are uS to now from the isr() trigger. Just bumped return math to return 10's of ns - harder to do math on screen :)

Not gotten to the RTC isr() - to see it enabled to create an rtcTimeStamp. Not seeing LED qBlink as it should so far. Then I can do a CB.mean to track average cycles/sec without doing it myself, so above 'times' are based on F_CPU expected not RTC timed yet.
 
Hi Tim. Yep your right the IMU is at 250 (can't divide anymore). The GitHub doesn't have any jar's you have to compile yourself, but I did that and its in the zip in the dropbox link that I posted in #330.

Think my problem is memory related - I am working on a laptop so all that coming through is probably taxing the memory. If I do less it works.
 
Don - Tim: I created a new message, 56, that pretty much just dumps 11 variable (pitch, roll, yaw, heading, Lat, lon, alt, veln, vele, veld) and have been plotting it for about more that an hour. Here is what I am seeing;
  1. pitch and roll are steady as expected
  2. Yaw - not seeing any real drifting but it does vary about 0 and -2 degrees (at mine does) maybe a little better.
  3. Altitude - forget it. Too much variation measured in 8-10 meters. Will stick with a pressure sensor :) Same as I see with a regular GPS. Would not relieve on it for knowing my real altitude.
  4. Lat is varying in a sinusoidal pattern varying in the 5 and 6 decimal place. Again would not rely on for accurately knowing my position. Lon is varying but not as much. Just as a note is was rock steady and fairly accurate in the early version. Didn't look at the code but maybe that change you talked about 10x10...
  5. Velocities are pretty much in the +0.02 to -0.06 (mostly -0.04) m/s. Maybe there should be a test that if its below a certain value velocities are zero?

Anyway these are just my observations from the data I have seen so far.
 
Tim - I'm back online, will download your version, update the buffer, and give it a try!!

Mike - Glad you're seeing what seem to be reasonable numbers. I see pretty much the same thing, sinusoidal drift on Lat and Lon, and fairly wide swinging Alt values. Since satellites come and go, I'd expect the LLA to "wander" some. At some point I want to try the unit away from my office to get a really clear view, suspect the wander will be much less.

I was thinking of doing the same thing with the 11 variables, or having two TViewer versions (one to look at LLA data, and one for the residuals "heartbeat" info, maybe even going to different screens).
Don
 
Don - glad your seeing the same thing. Wanted to make sure it wasn't me. Possibly with clear skies you will get better results :) hopefully.

Yes you probably could have two separate messages one with the residuals going to serial port 1 on the slave and the 11 going to the serial on the slave then you could point Telemetry viewer to the different serial ports. Tim could confirm this. Almost 100% sure MST could do it. It resides in the message id. That's the way modified the slave and the master.
 
Decided to run a little test on my little T3.5's with 2 different packets being send sequentially, since that's how its setup now in 2 separate print functions:
Code: 
56: 153.085556, -1.434259, 24.765715, -5.180302,185.367111, 40.774677,-73.814697,.....

55: 153.085556, -1.434259, 24.765715, -5.180302,185.367111, 40.774677,-73.814697, .....

56: 153.285477, -2.986793, 25.185202, -4.836743,185.710678, 40.774677,-73.814697,....
56: 153.490417, -2.438940, 24.685965, -5.084338,185.463074, 40.774677,-73.814697, .....
56: 153.690338, -1.763857, 24.581947, -5.317466,185.229950, 40.774677,-73.814697,....
56: 153.890259, -1.723196, 25.123049, -5.179851,185.367569, 40.774677,-73.814697,....
56: 154.090164, -2.890193, 26.033905, -4.667546,185.879868, 40.774677,-73.814697, ....
56: 154.295090, -3.351544, 26.152596, -4.427943,186.119476, 40.774677,-73.814697, .....
56: 154.490005, -2.383745, 25.800253, -4.574683,185.972733, 40.774677,-73.814697,....
56: 154.689926, -1.953225, 25.819233, -4.559110,185.988312, 40.774677,-73.814697,...
56: 154.889847, -3.482364, 25.213247, -4.477462,186.069962, 40.774677,-73.814697, ....
56: 155.089767, -2.743408, 25.040861, -4.602727,185.944687, 40.774677,-73.814697, ...
56: 155.284698, -2.662260, 25.529053, -4.412329,186.135086, 40.774681,-73.814697, ...
56: 155.484619, -2.041198, 24.220295, -4.947106,185.600311, 40.774681,-73.814697, ....

55: 155.484619, -2.041198, 24.220295, -4.947106,185.600311, 40.774681,-73.814697,....

56: 155.694519, -2.564337, 24.115517, -4.990655,185.556763, 40.774681,-73.814697,....
56: 155.894440, -2.620505, 24.646713, -4.858641,185.688782, 40.774681,-73.814697,......

if you notice packet 56 is being sent about every 0.2 seconds and packet 55 every 1.4 seconds Hmmmm. it should be one for one, so probably losing packets with F&F. If I run them separately its every 0.2 seconds for each packet.

Will have to try it from the same print function to see the differences but probably needs some time between sends to give it time.

Comments?

EDIT: If I reorder the print functions message56 is called at the transfer of message 55 from the serialPrint function it gets better but still miss firing:
Code: 
56: 27.656944, -1.638473, 25.034393, -4.513143,184.630844, 40.774677,-73.814674, 30.578005, -0.010996,  0.003116,  0.008850,.....
55: 27.836880, -1.127834, 24.565647, -4.820583,184.323410, 40.774677,-73.814674, 30.576214, -0.140083, -0.125985,  0.014053, -0.014053, ......
56: 27.836880, -1.127834, 24.565647, -4.820583,184.323410, 40.774677,-73.814674, 30.576214, -0.010916,  0.003325,  0.008866,......

55: 28.036812, -1.295388, 25.401436, -4.564151,184.579849, 40.774677,-73.814674, 30.574171, -0.146520, -0.125971,  0.014032, -0.014032, .....
55: 28.241734, -1.641307, 25.034927, -4.685209,184.458786, 40.774677,-73.814674, 30.571932, -0.140091, -0.126005,  0.014066, -0.014066, ..... 
55: 28.436665, -2.622952, 26.173449, -4.140064,185.003922, 40.774677,-73.814674, 30.569576, -0.144089, -0.125879,  0.013883, -0.013883, ....
56: 28.436665, -2.622952, 26.173449, -4.140064,185.003922, 40.774677,-73.814674, 30.569576, -0.011306,  0.002839,  0.008855, .....

55: 28.651592, -3.369629, 25.864395, -4.047187,185.096802, 40.774677,-73.814674, 30.567047, -0.146013, -0.125637,  0.013456, .....
56: 28.651592, -3.369629, 25.864395, -4.047187,185.096802, 40.774677,-73.814674, 30.567047, -0.011634,  0.002745,  0.008880,......

55: 28.886505, -2.272371, 25.675386, -4.180553,184.963440, 40.774677,-73.814674, 30.564121, -0.146643, -0.125609,  0.013412, -0.013412, .... 
56: 28.886505, -2.272371, 25.675386, -4.180553,184.963440, 40.774677,-73.814674, 30.564121, -0.011454,  0.002851,  0.008859, ....
 
Last edited:
Tim,
Got your Doubles version running, nice!

I'm going to take a bit of time now and try some IMU re-calibration. Want to see if re-calibrating gives me new cal numbers and maybe tighter EKF soln (heading). Also curious if repeated cals give me the same cal numbers.

Don
 
The T3.x series have FIFO for both Serial1 and Serial2, if you ever run out of UARTS MST can access uarts from the slave, you can pass the MST_SPI object to a library that uses uart communication and it’ll access the UART at full baudrates, Mike, that includes hooking up the ESP to the slave and using library on master side to access it at 3megabaud :)

Don, don’t think you just have 2 USBSerials, you actually have 8 i2c busses (2x3.6’s) and 12 uarts functional on SPI_MST
 
Queue size is 8, I reduced it from 12 (not a power of 2:) Think slave is still working so it missing packets. Thinking either make the queue larger or try a slight delay between packet sends.
 
"includes hooking up the ESP to the slave and using library on master side to access it at 3megabaud" => going to get real confusing real fast.

Yes Don, accessing a I2C device on the slave does work :)
 
Don Kelly said:
Tim,
Got your Doubles version running, nice!

I'm going to take a bit of time now and try some IMU re-calibration. Want to see if re-calibrating gives me new cal numbers and maybe tighter EKF soln (heading). Also curious if repeated cals give me the same cal numbers.

Don
Click to expand...

Good! That will buy me some time - too many distractions and too little sleep to focus well yet.
 
The easiest way to get a second TViewer would be to go back to Serial# for coutD - and use Master Serial/USB for the second TViewer. That would still add a 3rd Teensy and USB cable - but I have three bundled already with that still connected.

Noted before for all that Serial1/2 have that FIFO - but as observed even feeding those slower devices and the associated interrupts can slow the system when they get busy. Setting up a second Slave w/alternate CS wouldn't be too hard - except when it comes to shared wiring for common SPI lines - my Teensy's in use have female headers so wiring 1 to 1 is easy - I don't have 'Y' wires - might be easy enough - but more fragile - and more wire for noise.
 
mjs513 said:
Decided to run a little test on my little T3.5's with 2 different packets being send sequentially, since that's how its setup now in 2 separate print functions:
if you notice packet 56 is being sent about every 0.2 seconds and packet 55 every 1.4 seconds Hmmmm. it should be one for one, so probably losing packets with F&F. If I run them separately its every 0.2 seconds for each packet.

Will have to try it from the same print function to see the differences but probably needs some time between sends to give it time.

Comments?

EDIT: If I reorder the print functions message56 is called at the transfer of message 55 from the serialPrint function it gets better but still miss firing:
Click to expand...

It might be handy to have a way to do a transfer16_QUE() - where rather than sending NOW would just push that transfer into the OUTPUT queue and return. Then in loop() have a call to .events() that would not only look for return data from Slave but also push out one of the queued transfer16_QUE() requests. These events are NOT time critical - but this would assure they are sent from loop() when there was free time - and also not jammed out back to back that may catch the slave busy with USB output or other distraction corrupting the message?

Now that .events() has the Time Limiter - it could be applied to the de-QUE calls to Slave as well to prevent hitting it too fast and allow the Master to control the output rate as needed.
 
id worry more about queue filling faster than queue dequeueing :)

either way you cant send and receive both, its separate transactions
for the master if we queue and exit, almost definately it would fill immediately
 
tonton81 said:
id worry more about queue filling faster than queue dequeueing :)
Click to expand...

Loop is currently being called 370,000+ times per second on my busy system - that is plenty of opportunity for .events to process in a timely fashion - if the delay between sends was set to 10 ms ( 0.01 seconds ) - that would be 100 chances to transmit each second to allow the Slave to process them and probably 2 or 5 ms would be enough to get the first message processed. My T_3.5 Slave has processed about 990 complete ( 851 char messages ) per second - so even 1 ms is enough of a gap - but there needs to be some separation - IF as it seems back to back messages is behind the LOSS.

If mjs513 could transfer16( #55 ) and transfer16_QUE( #56 ) I think things would run very smoothly. _QUE could be either an added optional PARAM - or a second interface?
 
Guys, the packet 55 is sending about 11 of the same doubles as packet 56 so probably should delete from packet 55 and just use packet 56. But that's the realistic way of looking at it. I am o)ut of curiosity just going to increase the que size to 16 (not 12) and see what happens.

The other option is just sending it to one of the slave serial ports like serial1 or serial2 (packet 56 info) but I want to try this way first.

EDIT:
With both T3.5's at 168Mhz and buffer increased to 16 missed a whole lot of packet 56's but 56 came through ok.
With slave at 168 and master at 144 it got better missed a whole lot less.

EDIT2:
With both T3.5's at 168 and buffer back to 8 and a 2ms delay between packet transfers have not seen any missed packets.

With a 1ms second delay same thing. Not seeing any missed packets. Packets alternate as expected
 
Last edited:
You must log in or register to reply here.
Back
Top