[Solved] TC3.8_4 Real Time Upgrade

[Rich]

Hi MTCAT

... Seems like there's something else going on as well, the Vortex is having a bit of a hard time with display related duties I think, the continuous stream, which can be displayed as it's collected (if the continuous tab in the GUI is selected), seems kind of "jerky" and I notice the seconds counter in the GUI jumps a bit irregularly sometimes to "catch up" with tinierclock.sh for example, ...

If you disable or at least minimize screen updates, does it still choke at 200 KHz?

[MTCAT]

Hi Rich,

Last night it ran for a little over 3 hrs at 200 kHz with a 240k dma_blk_size leaving the GUI on the transient screen, I collected a few transients but overall there was very little screen refreshing going on, about the only thing that got updated really was the time. I think the dma_blk_size does help as some (smaller) sizes are definitely worse, running for like 10 or 20 minutes, so maybe the larger block sizes helps to mask this "other" issue, which maybe is the screen updating ?

In the end I'll be running this off the LVDS line, on a small 9 (?) inch LCD screen, right now I'm using VGA output on a "big" 15 inch NEC LCD monitor, maybe that's irrelevant, I don't know.

Thanks,

David

[MTCAT]

Hi Rich,

I still haven't been able to get the acquisition program to run 100 % reliably at 200 kHz sample rate, I did find some old e-mails from 2015 from Peter who had the exact same issue with the Pentium SBC we originally purchased, Peter said he solved this problem by changing from pipe communication betweem mt_adc and mt_logger to shared memory. Only problem is, I'm already using the shared memory version of the program with the Vortex so...., do you think it would be worthwhile to "profile" the program to ideally see where the Vortex is spending the most time ? I guess I can compile with "-pg" option, run the program, exit normally, and then run "gprof" on a file called gmon.out.

Otherwise, maybe I just have to accept running at 100 kHz max, it seems 100 percent reliable at that.

I could try running it on a smaller display, at lower resolution, I'm not sure if that would make a difference though, there's a lot of information out there on how to use Cairo graphics library for fast drawing, most people say 20 fps is about typical, which is what Peter is using as well (50 ms), I tried 100 ms (10 fps) and it actually was worse, more jerky of course but also failed even faster, also tried a faster 40 fps (25 ms) and that didn't seem to help either.

By the way, I was able to get rid of that error when re-setting the parameters from within the GUI, so now I can change sample rate, ADC scales, etc, w/o getting an error and having to re-start the program, so that's something at least.

Thanks,

David

[Rich]

Hi MTCAT
Video activity can be resource intensive. The way I understand it, DMA transfers take place whenever the system bus is idle.
That means while the CPU is fetching instructions to execute or updating the display, DMA activity will be blocked.

Having said that, you might want to address the question in reply #375.

[MTCAT]

Hi Rich,

Sorry, I wasn't dodging that question but was doing more analysis, yes, unfortunately, the program still does choke at 200 kHz sample rate, even when it's left on the transient screen with minimal screen updating, and seems like the dma_blk_size has a minimal effect as well, once it gets larger than a certain size it doesn't seem to matter very much, i.e., 120 k sample seems about as good as 240 k sample ( I think anyway).

The loop_interval_timer, which I think controls how fast the the GUI is refreshed didn't seem to help, I tried both 10 Hz and 40 Hz, the "normal" setting is 20 Hz.

I ran it today at 100 kHz sample rate (240k sample blk_dma_size) leaving it on the continuous screen, and it ran for almost 8 hrs, it crashed not too long after I brought the screen back to life, was also going to try turning off the screen saver, I found a post of yours that says "xset s off -dpms" will do it. So not even 100 percent reliable at 100 kHz sample rate it seems.

Maybe tonight I will try running it at 100 kHz sample rate, on the transient screen, with the screensaver off, and see if it's still running in the morning.

Thanks,

David

[Rich]

Hi MTCAT
If the display is updating a waveform, especially if it is scrolling it like a stripchart recorder, that will probably chew
up a bit of processor time.

It's possible the computer just isn't fast enough. Or maybe you just need faster video hardware.

[MTCAT]

Hi Rich,

I was able to run the program for 16 hrs at 100 kHz sample rate with a 240k sample dma_blk_size, with the screen saver off ("xset s off"), and the GUI on the mostly non-updating transient screen, however, at 200 kHz sample rate, it only ran for 90 minutes under the same conditions.

I then lowered the dma_blk_size to 200k samples, and the program ran for more than 12 hrs at 200 kHz sample rate !!, so that's a new record, it actually ran the battery dead (overnight). The 200k sample dma_blk_size is where I previously had the best success with 200 kHz sample rate (2.5 hrs, with screen saver on, and not leaving it on the transient screen all the time).

I guess I should run it at 100 kHz sample rate with 200 ksample dma_blk_size but maybe keeping the screen on all the time helps too.

Otherwise, could lower resolution to 800 x 600 ?, would have less pixels to draw and should also be a help I would think.

But maybe, if I leave the screensaver off, and leave it on the transient screen, might be able to squeak out 200 kHz sample rate reliably, 800 x 600 might give it a bit of a cushion too.

Will have to run some more tests I guess, am also going to run it on the smaller 10 inch LCD screen, which is what's going to be used in the field anyway.

Thanks,

David

[MTCAT]

Hi Rich,

Update, I think I got the little system going pretty good now at even 200 kHz sample rate, 200 k dma_blk_size, xset s off, and leave on transient screen, seems to run indefinitely at 200 kHz or 100 kHz sample rate !

Having problems with the DRACAL temperature sensor though (USB-TMP125), it needs a newer version of libusb-1.0 it seems, the DRACAL software won't compile. I did install digitemp 3.4 though, and it built just fine, so I have some simpler (and cheaper) temp sensors on the way that work with digitemp, so hopefully that will work, to have some real temperatures to report within the GUI.

On the GPS front, I can't buy the U-Blox EVK-M8T's at the moment (apparently there was a fire at a crystal factory in China U-Blox told me) so I'm building my own little GNSS timing solution with ZOE-M8Q from SParkfun, can configure it with a UART to USB adapter in Windows, and then use it for TinyCore with a TTL serial to RS232 serial level shifter. This is a lot cheaper than the EVK-M8T's as well.

Once I get the temp sensor and the new GPS setup going I'll have to modify the nice scripts you made for me to get the temperature readings out of a new csv formatted log file, and for the GPS, I would like to try to make use of new (to me anyway) NMEA sentences (GPGSV, GLGSV and GAGSV) to report the total number of GPS, Glonass and Galileo satellites, right now, we're using a NMEA sentence that reports the total number of GPS satellites only.

I also increased kernel.shmall (which Peter said should be done, but not sure if it's truly necessary) and set the "keepalive" time smaller but the latter unfortunately didn't solve the network problem (I don't think), when downloading libusb package I still had to get ping going in another terminal else it just stalled, hmm, problems to be fixed for another day, can always use USB to offload data as well.

So that's about it for me, THANKS SO MUCH, for all the help, I think this thread should be marked as SOLVED (and then some).

Thanks,

David

[Rich]

Hi MTCAT

...  I think this thread should be marked as SOLVED ...

Done. 

[xor]

For single core processors this may be possible,
but for multi core processors RT core seems not possible!!!

https://github.com/rtic-rs/cortex-m-rtic/issues/204
It's not possible to share resources (static mut variables) between cores.
However, it is possible for one core to initialize another core's resources and
it's also possible to share static variables between cores.