CLI Example for Sensor Box Pro

[Smithson]

The sensor box pro is a neat device.  If I use the CLI Example program and the USB cable, I can get 8000 data points per second, if I use a traditional C# program I get 8 data points per second.  

The CLI yields dat files, which can be read with a simple C# program, although why you would mix 6 and 4 data groups is beyond my skill set to understand, but it is easier to use than Python and MEMS Set.   And it is easier to do the byte data in C#.  (It took less time to write this program than I spent trying to get Python to work.)

CLI Example makes me type enter to start.  I have many ST.COM accelerometers all over the world and I am not going to type enter to start, but the main.cpp and main.h and the cmake lists file will not compile in CMAKE or Visual Studio.  So I cannot fix the challenging feature. 

Could we get VS SLNX file and the C++ code for this program as part of the SLNX so it is easy to take out the enter statement and break the output up into data sets that can be analyzed in near real time, like 8 seconds on a bridge in a snow storm in the middle of the night, whilst I am sound asleep 1000 miles away.  

 

This will read your dat files. there is some junk in there as it took me a while to work out the byte structure as the documentation shows a nice picture, but it is without numbers.  

 

I need to improve the routine to break up the bytes, but that is ok as long as the accelerometer is flat. 

One looks for say 8 seconds of record, time for a truck to pass over the bridge, do a FFT preferably in Intel Fortran but who cares and the record the data. After a year you have 3 million records and we then have a good idea about the bridge.  

I would upload a picture to show some output, but it will not let me.  

Thanks.  

<< Cannot include code as message cannot exceed 30000 characters. >>  

The file type (.cs) is not supported. Valid file types are: ai, avi, mp4, bmp, csv, doc, cpd, docx, flv, gif, gz, tar.gz, har, ico, jpg, jpeg, log, mov, mpg, mpeg, mp3, odt, odp, ods, pdf, png, pps, ppt, pptx, rar, rm, tif, tiff, txt, xlr, xls, xlsx, xml, wmv, wav, z, 7z, ioc, hex, c, cc, cpp, h, hpp, tar, xz, dts, s, zip.

One is left to wonder.  Ah, I compress to zip.  

 

[Smithson]

"lps22df_press": {
						"c_type": 0,
						"data_type": "float_t",
						"dim": 1,
						"enable": true,
						"ep_id": 3,
						"fs": 0,
						"ioffset": 2.002014636993408,
						"odr": 0,
						"samples_per_ts": 1,
						"sd_dps": 16,
						"sensitivity": 1,
						"sensor_annotation": "",
						"sensor_category": 0,
						"st_ble_stream": {
							"id": 5,
							"press": {
								"channels": 1,
								"elements": 3,
								"enable": false,
								"format": "float_t",
								"multiply_factor": 1,
								"odr": 1,
								"unit": "hPa"
							}
						},
						"stream_id": 3,
						"usb_dps": 12

The measureodr in your config json file throws an error on reading saying it cannot be read as a string or an int.  

[Smithson]

The temperature equation in your data analysis program says the temperature is 30 C when we keep the room at exactly 22 and we measure it with four different devices . 

 

[Smithson]

The picture shows the C# code to translate your dat file.  The two critical rates are the 2308 and the 1000.  

The picture is the configuration file, it shows 2304.  And the program works with 2308 not 2304.  

0.0001226665221321810

The mems studio outputs the CSV file, but the number of decimal places makes it hard to check your multiply factor.  The % error I cannot solve for as the input data is not accurate enough from the mems studio to calibrate properly, it is not important, but it was interesting for a while.  The last column is the % ratio between your mems studio and my estimate of the number.  It bounces around due to the rounding error in the mems studio output. 

Is there as way to get more places from the mems studio.  You will notice that the first X and Y values are the same, statistically improbable, but the third X and the second Y are the same.  It is interesting and after looking at very many acceleration data files, I have not seen this before.  It might be me. I will check.  

 

The MEMS studio gives me 741001 output lines of acceleration data.  Using the same files and my C# program, I go past the 741001.  Here I am showing you 6000 past , the 0.000 is the lack of data in the mems studio file.  

I get 100.23 seconds and a cycle rate from the json files, do you know why the MEMS studio misses the data.  I cannot determine if it is accurate as I lack your data.  The MS 1948 is the number of 2308 cycles, the 4495984 is correct.  I had to hunt for the 2308, can you confirm the 747036 line is a four byte number, I cannot find a reference to it in the manual except to say it exists. 

This is the time stamp, 1000 lines per time stamp.  Just out of interest is that constant or a variable set in one of the many files,  as noted earlier JSON readers did not like your device json file.  I have to figure out my mistake there. 

My 19yr old daughter told me I have been ratty these last few days.  If you are wondering about ratty read the Wind in the Willows.  

The Sensor Tile Box is really good, your manuals are about their usual interesting level of technical information.  

 If you write in C# we can disassemble the code, I have an accelerometer in Cedar Rapids Iowa.  It has been running for 9 years with the same program, now I have to disassemble the manufactures DLL and update them to the latest Windows and MS standards.  It is not difficult just interesting.  The devices last for ever.  The Intel NUCS not so.  

I do not expect a reply

And this is the bridge at Lansing Iowa that we monitored for two years. this is the day it was blown up.  It had been closed for safety inspections in the last two years. On the top of the pier in a space about 2 feet by 2 feet about 10 feet below the deck and you had to climb down the steel in full safety gear and attached sensors on the outside.  We used the MKI 210 - I think.  Nice little device, aside from the annoying habit it does not restart if the computer cycles.   We can solve that with USB managed hubs.  It is ok the strain gauges have the same problem.  

I would like to use the tile box, but the software needs some work.  It is ok, I am used to that.  

 

 

John

[Smithson]

Here is the C# code.  It is not perfect, but now I can do FFT and produce pictures. 

The interface will not let me load the picture of the tilt data on the bridge. It is enclosed.  

This is why the MEMS studio output number of digits is important.  

[Smithson]

The 2308 selection and the 1000 selection will intersect at 1.4 days or there abouts.  

What comes out when you have the same data point and it needs 2308 and 1000, you will break the pattern and need to say which pattern you are using.  

Our longest record is 9 years from a single accelerometer, so it is of some interest.  

I am sure there is an answer. 

[Smithson]

The picture is from your manual

It clearly says time stamp

------------------------------------------------------------------------------------------------------------------------------------------------------ 

Timestamp values are accepted in the format "yyyy-MM-dd HH:mm:ss. SSSSSS" , and can consist of just the date, or just the time, with or without the fractional second portion. For example, you can specify TIMESTAMP values such as '1966-07-30' , '08:30:00' , or '1985-09-25 17:45:30.005' .

-----------------------------------------------------------------------------------------------------------------------------------------------------

This clearly defines my idea of a time stamp.  

Your data file has time stamps every 1/7th of a second, give or take a moment, 

This is my print of the first date at the 1000th location or byte offset 6012.  

If I use a hex editor I can confirm the data. 

So using the C# methods I got the byte code for the current date and time and added 100 seconds.  So the data that I recorded yesterday should have a 72 as the last byte, it has 63.  

You output in your csv file the time in microseconds. From the first 10 entries.  

time[us]
350032
350166
350300
350434
350568
350701
350835
350969
351103

I am stumped as to how to get from your bytes to the time in microseconds.  I can have a guess, but the long and the short integers do not add up to the numbers.  Obviously I am missing something, but I know not what?

So whilst I was thinking on this problem I was thinking about a name for the program, I use God's names, Zeus etc...

But I thought about the guy in the bridge too far who carried an umbrella, his name is shown on the picture.  

Incredibly brave soul, so I chose that name.  At the time the umbrella picture comforted me as I struggled here.  

Why would you run an accelerometer at 7000 Hz, we cannot see any movement data above 500 Hz in the FFT. 

Trust me I have looked at a lot of FFT's.  

The attached file is a FFT from the CX1 accelerometer from a London tall house of masonry about a week ago with the signal picked up from the train line about 150 metres away.  

The FFT analysis is interesting.  

 

[SimonePradolini]

Hello @Smithson 

You did so many tests. I'm happy to hear that you’re finding a promising solution, but I need some clarifications to fully support you.

Can you confirm me which firmware is running on the SensorTile.box PRO? Are you referring to FP-SNS-DATALOG2 v3.2.0? Have you already checked the User Manual and Quick Start Guide?

Are you aware about STDATALOG-PYSDK v1.3.0? It's the Python SDK natively supporting the DATALOG2 ecosystem. It includes ready-to-use scripts that you’re free to run and modify to fit your use cases.

 

When received those confirmations, I would come to you with further question to understand the specific bugs/issues you’re addressing.

 

Best regards,

Simone

[Smithson]

Dear Simone:

I am running the firmware that pops up after you install the 1.0.0., I think it is called 1.3.0 or some such.  

No experimental engineer who has 8 seconds cycle time for a warning on a bridge issue is going to use Python.  

I prefer Fortran - Intel which the great grand child of Microsoft Fortran.  But using it takes longer. 

But I use C# here and now as I have for all of the ST.COM Accelerometers.  You have a lot of software in C#. 

It is not difficult to write in C#.

The hardest part was to find that the sample rate for the 4 byte elements is 2304 on USB cables and about 15000 to SD cards.  Now I have that worked out, the remaining issue is the double copied elements.  That is a bit longer. 

I want to deploy these to remote locations, so a copy of the CLI Example that does not need the enter to start line would be great.  Decompiling a C++ program like CLI Example is a pain.  

It is a nice little device, I have a bit to learn, but here is the C# code so far.  Once it is running I will put it on git hub. 

I do not understand the time signal bytes, it does not translate into a meaningful number, neither a date or a timespan.  

Thanks for the reply. 

 

John

 

 

 

[Smithson]

Code.  It has some directories hard coded, that will change, but not for a while.