Time and direction into vectors for oled roadmap

Hi everybody :slight_smile:

I hope this hasn't been yet posted in other topics...

I'm newbie in Arduino and I am looking for code informations to create a box equipped with a nano, screen oled and piezos which could collect the ​​i2c values of both a compass and a timer, to record them every 10 seconds ( for example ) then would, with each change of heading or every minute, display the resulting vector ( heading + time ) at the following of the previous vector displayed.

A kind of road book created by the user during his journey showing the time spent on each heading.

The use is simple and would come in addition to the compass and lines we use during cave diving for the main purpose of topos surveys for exemple.

I already have the case and piezo.

The question is whether it is possible to easily apply a code to display on an oled:

  • the current bearing,
  • cumulated time ( or approximate length using the accelerometer?) for all vectors created
  • the track created and saved on a sd card.
    In an ideal world, using the piezos to signify the half turn or stop or pause, and then on half turn invert the created display and scroll to check the infos logged, would be also great though...

No need for background, impossible to use gps tracking in this environment, so any good advice will be really appreciated for this project...

Any idea?
Thanks for your help :slight_smile:

Cedrick, France.

Why is GPS impossible ? Are you in the Nautilus, twenty thousand leagues under the sea ? Or on a journey to the center of the earth ?

You are missing the speed. Therefor you can not create a track.

Do you know what a tilt-compensated compass is ?


As I said in my post : GPS simply don't work in caves 3 or 4kms long :smiley:

We're not speaking about a journey to the center of the earth, but only about up to 5 hours underground diving and walking :slight_smile:

As I also said : the timer is the second info, not the speed. So, I guess time+direction could easily give a vector? We for exemple use gribs files for sailing that include strength of wind + bearing. TMO, a value is a value. But maybe the accelerometer could give a speed.

Yes, I know what a tilt compensated compass is.

I guess I didn't read your question very well. Sorry for that.

The length and the track is really a problem if the speed is not known.
It is possible to show a direction (I think that is what you call the "vector").

Using the accelerometer to determine the speed and position is possible indoors for a short time and only a number of meters. But the sensors are noisy and drift.

I suggest to get a accelerometer + gyro + magnetometer and calculate everything with a standard library. Perhaps you can use the direction. I think it will be very hard if the box can be held in every way. Using the accelerometer to determine in which direction (with the compass) the box is moving will not be easy.

A common sensor with a standard library is for example the MPU-9250 with AHRS filter.
Kris Winer has made code for that: GitHub - kriswiner/MPU9250: Arduino sketches for MPU9250 9DoF with AHRS sensor fusion

His newest code is with a MS5637 barometer. I think that is useless under water. It would be nice if a water pressure sensor was added to calculate the depth.
For now, the MPU-9250 with AHRS is a good start, in my opinion.

Awesome video :sunglasses:

1/ You're right, it's gonna be difficult to get precise values from the MPU even with a AHRS. If I understand, maybe making an average of the bearings collected over a minute could be the solution?

2/ If I understand how it should works,

  • the values written and collected every mn are "time" and "MPU-9250 and its ahrs filter bearing or the average over a designated time lapse ".
  • They can become "variables" that can be stored using the IDE and then be collected when needed ( let's say the last variables created or the variables created concerning the last mn, which can be convenient but could create some troubles later on for the display ).
  • They can be "applied" to or with a "constant" which could be the lenght of the vector for 1mn.

The main problem then is : how to screen each new vector following the last one without deleting it.
Two possibilities then :

  • either display every vector following the last one every one mn. Ok that's the original idea.
  • either calling using piezo every stored vector but that would display any vector only by one mn samples...

So, I guess the simplest solution would be to :

  • get rid off this "vector" thing and
  • only create a displayed logbook with a line created every time the bearing changes in a significant way ( let's say 15° ), then displaying for each significant bearing one line with " everage bearing calculated", " time spent following this bearing", " total dive time at the end of this period" ( we only use this method for our deco plans and with our dive computers, anyway. Moreover, this value would tell us roughly how much time is needed to get back. So even better ). Piezos would be used to navigate among this logbook.

Only left problem : the bearings stored in the logged book need to be corrected to show the correct heading for the return. So, even if its possible to correct the heading to display it correctly in the log, we still need to acces to the initial datas for topo needs

Koepel, you did great for giving me a better start for this project tlaking about adding the depth value :slight_smile: I don't need any shield, just to display a log of stored values. Am I right?

1 ) yes, you need to sample continuously. An average every minute is no problem.

2 ) I do not understand everything you wrote.
Displaying and storing and calculating things can be improved later. You can start simple.

To store a lot of data, a serial EEPROM is cheap. I think the AT24C512 is 64kbyte for less than 1 euro.

To display the heading for the return is what programming is about.

An OLED does not require a shield. But there are a few types of OLED. If you want a OLED that works (and with a matching library) you end up with something like this: Monochrome 1.3 128x64 OLED graphic display - STEMMA QT / Qwiic : ID 938 : $19.95 : Adafruit Industries, Unique & fun DIY electronics and kits

ok so making an average including all samples made during a minute is ok
Storing is made using the AT24C512, ok.
The Oled, I have to check the exact room available but a 2.7" would be easier to read underwater, 1.3 is really small even if it seems perfect at first.

So, we have now two needs :

  • one log book including the data collected w or wt the average made ( for the topo needs later on),
  • and one log book with the “return” heading.

Could the return just be calculated and stored like this in the second logbook : if heading value>180 then display value-180, if heading value<180 then display value+180 ?

What are your programming skills ?

Detecting the direction when the box is moving is a very hard. I don't even know if someone has done that.
A software engineer would not need a logbook with the return values, just the stored values are enough to calculate them.

Maybe you could ask another question on this forum. For example "How to calculate the direction when carrying a box with a MPU-9250". I doubt if someone has the solution, and I don't have it either.

When you ask a follow-up question, add a link to this one, so others know the background.

No programming skills...

So, if I understand what the problem is, you mean there's no magnetometer that can be connected to Arduino and deliver a heading?

I then have to think about this before posting a new question on the forum. Thanks a lot for your help Koepel :slight_smile:

A magnetometer shows where the magnetic vector points to. That is not to the north at the horizon, it can point upward or downward. That’s why a tilt-compensated compass is important. To measure to direction to where you are walking is hard to determine. It is easier with a car that goes straight most of the time with a few turns.

I think that it can be done, and someone should do it. But this is not for a beginner.

Ok, but let's say it works on three axes, and that z is the axe for height. Why not using mainly x and y while minoring z for keeping a small tilt function? Koepel, in fact I don't really understand why a tilt compensated, rather than a simple module like the HMC5883L for exemple?

When you would have it in a box that you carry with you, then the box is hardly always flat horizontal. Because of that and because of the magnetic inclination the compass will be inaccurate.

http://www.magnetic-declination.com/ (it also shows the inclination)

You could do a test, perhaps it is not so bad. I think you might need a software engineer to make that for you.

The compass is usually flat because put on a dpv arm or held in front of the diver during the dive if needed. But what is working best , you're right, is compasses permitting a reading up to 15° inclination.

I guess the project is far to complex for replacing actual tools. I'll then wait and see if future created projects around arduino or Raspberry will match for this kind of use.

Thank you a lot for your help and informations, Koepel :slight_smile: