"Mercator Origins": Sat Nav & Telemetry for Divers

Hey Scuba Fans, Mercator Makers and Arduino Artisans!

I'm on the island of Gozo with my dive buddy Curt and of course Mercator Origins has been brought along for the ride.

YouTube doesn't let me do live broadcasts, presumably because the channel is very young or I have too few followers (hint  hint!) .

Anyway, Facebook Live is all good. I'll be having ad-hoc live broadcasts during the time we're here. You can also see the live broadcasts I've done to-date.

Follow me at  Scuba Hacker Mark's Facebook page 

It will be great to have you join us!

Oh my.

I have a core dump that is restarting the Mako microcontroller / M5 Stick. It started showing up yesterday evening in anger, and I did what I knew I shouldn't do but did it despite itself... kept going for hours trying to fix it.

Yesterday evening, I was using Qubrito to gaze lustfully at the cornucopia of metrics (66 at last count) that Mako and Lemon (the float microcontroller) are spewing out on a 500ms duty cycle over the interwebs. And then I saw the evidence... Uptime for Mako was much shorter than for Lemon... in fact by the time I'd finished fettling with it Mako was struggling to stay up for 2 minutes. Ugh!!!

So I threw the towel in, as I should have done hours before and have recommenced this morning afresh, this time with a proper strategy.

1. Add feature switches for all the features of Mako. This includes guidance, sensor readings, sending uplink messages and a few other things.

2. Make sure the conditional compile preprocessor directives for building into the binary Twitter, SMTP, Qubitro and Elegant OTA (Over the Air code updates) are all square.

3. Add uptime to the Mako display in seconds from boot. It's then easy to check if after leaving it to run for a time whether there has been a reboot whilst I've been away.

So how is it going? Well I've discovered something interesting. I've disabled everything that I thought could be causing the problem, and still the reboot (caused by a core dump no doubt) is happening though according to uptime it took 20 minutes on the last event. 

It's now time to add a way to disable the OTA update capability (which is actually a webserver which must be using the second core) through the UX. I have to be able to enable/disable through the interface as I will need to disable it for the test and enable it for uploading the next build. I do not want to open the console and disassemble innards in order to get access to the Stick's USB port to do a direct code update via cable!

Update @ 12.20pm - I can now disable OTA Async Web Server and Wifi separately whilst Mako is running using the physiclal GoPro case buttons. The current test run has lasted 53 minutes without a core dump / reboot, that's with OTA server disabled and WiFi still enabled. I am hoping we're done with this. I'll give it till the top of the hour, re-enable all the fancy stuff and run it again.

My buddy Curt and I are heading to Gozo for a week's diving. All being well, you'll be able to see my live dives using Mercator Origins on this Qubitro dashboard: https://portal.qubitro.com/dashboard/bb326327-4fad-4de0-88b0-a9f84011d70e

If you don't catch me actually diving (I will try to remember to post prior to the dive) then you can open the depth profile chart and see what's been happening today and over the preceding days.

Wish me luck!

I've just spent nearly two hours tracking down  a nasty crash caused by increasing a buffer declared within a function (ie on the stack) from 1024 bytes to 4096 bytes. Of course I did lots of code after doing this and before doing a compile so I had no clue that this was the root cause.

Lesson is... embedded programming is substantially different than Windows/Linux development so small changes, like in this instance only 3KB, can cause a problem. I have ended up using far more globals than I would normally in Windows/Linux dev. Also the Arduino IDE is designed for absolute beginners, which is great as it gives the lowest level of friction for progressing quickly with your embedded projects, however it does pretty much force you to use one code file (not even a .c file, it has to be suffixed .ino) and it is a bit strange in its behaviour when compiling. eg you don't need function prototypes forward declared of their first usage (where the function code is below in the text file than the call). This also results in rather misleading error messages when compiling too. However, I can't complain - it's been great to not have the bloat of visual studio with all the admin stuff that is associated with.

However, when I get back from my dive trip to Gozo it will be high time to bid adieu to the Arduino IDE and setup either PlatformIO or Visual Studio Code.

Here's some really detailed info on how to reduce memory usage, which also mentions minimise the use of the stack. It's for the Espressif dev environment but it's fair to assume the guidance crosses over to the Arduino IDE / build environment:

Espressif API Guide - Minimise RAM Usage

I've had a lot of progress these last few days, mostly to do with internet integration but also some final upgrading of non-silicone wires in the enclosure. I've also had the console operating undocked from the cable and mothership/float and working using a hefty onboard battery (had to take Tiger M5 Stick out to do this for space reasons).

However, long story short - at one point yesterday I ended up swapping out the Mako M5 Stick (used for navigation display purposes in the console) with a new replacement. I thought I'd damaged the original one. I was trying to solve another problem at the time, so didn't notice the digital compass got stuck showing the same number 187 degrees.

And the reason why the compass got stuck was because there are two small but quite powerful magnets inside every M5 Stick case. These need to be carefully removed from both Mako (navigation unit) and Tiger M5 Stick cases otherwise the compass is effectively broken.

I'd forgotten all about this when I swapped in a replacement for Mako. Instead of opening up the new stick and taking out the batts, I replaced the original one as I'd subsequently found out that there was nothing wrong with it.

ooooh... Adding both SMTP send email and twitter libraries busted the program space limit on the Mako M5 microcontroller. Doesn't matter, I'll ditch the email bit for Mako.

I want the world to build Mercator Origins, and more specifically young people, to have them get interested in pursuing engineering and STEM subjects as a career.

Patents don't interest me (edit: but see my latest comments below). The first patent was granted - or the equivalent at the time - in the 16th Century. The concept of patents is not fit for purpose for the 21st Century, open source is the way forward and there are plenty of ways to monetise off the back of it if I really want to in the future - eg providing an optional cloud SaaS service on top. See my structured cable supplier's website to see how to smash out of the park monetising open source UAVs and ROVs: www.bluerobotics.com

I would need to patent in every juristiction separately: UK, EU, USA, Australia, the list goess on. And then there is nothing stopped someone or some company in any country copying all the ideas.

To block someone abusing a patent in the UK I would need to issue a high court injunction, requiring the services of very expensive barristers. It will then take a very long time, and be very difficult to prove a breach of patent. A patent takes 4 years in UK to grant anyway, and I would need to keep everything secret until I applied for the patent - and of course it does not tip a hat at iterative development. I would have to outline all my ideas and concepts in that one waterfally application.

Nope - not interested. This is first and foremost a hobby project that I am doiing for me, whilst also giving back to the software development and maker community and the scuba community. I have taken advantage of open source and public domain applications and code since I was a teenager and NEVER given back.

This is my way to give back, whilst also raising my profile. I have hidden behind my keyboard all my life and due to the recent help of some very special professionals I now have the confidence to make a public impact in the world. That is worth it more than cash to me.

Carry on soldering and Expand your World with my invention Mecator Origins, but please know that I'm not interested in market size, etc. My priority at least for 2023 is to make a positive impact on as many people's lives as possible, including especially those who are at the margins of society.

Thanks! This is what the Scuba Hacker stands for.

Very excited to tell you all that the two test dives that have confirmed Mercator Origins' metal have now been published to YouTube!

Here's my brand new, freshly minted YouTube channel created especially for the SupplyFrame Hackaday 2023 Prize entry!

Channel link --> www.youtube.com/@zxfan      do please Like, Subscribe and enable notifications for new videos!

Dive Zero - no electronics test - make sure the enclosure doesn' t leak or implode at 10m, checkout the human factors of diving with the spool, how does the spool and cable feel in my hands when diving?

Dive One - All systems go! Mercator Origins fully populated with electronics, very exciting for me to take my creation to where no other Scuba Hacker project has gone before :-)

And here's a pressure pot test to a stonking 56.5m dynamic and 46.5m 30 minute duration, using a device of my own building, though not my design (see my photo elsewhere for a credit to the designer)

www.youtube.com/@zxfan

These have been the most fun videos to prepare for and shoot to date.

It's all about encouraging young people to get interested in science, engineering and scuba diving/snorkelling to appreciate the underwater world. Both are flagged in Youtube as suitable for kids, so it might show on the YouTube Kids app - I'm not familiar with this though. 

Please share with young people and their families.

www.youtube.com/@zxfan

https://github.com/scuba-hacker

I've done (another) thing... and I'm so happy to finally be sharing my biggest and best personal coding project with the world! The engineering manager finally has the confidence to reveal his code... and this is only the start. I plan to upload all my significant historic projects, including a quantum entropy simulator written in GFA Basic for the Atari ST.

TLDR: Scuba Hacker is planning to add Artificial Intelligence to Mercator Origins to create an optimised dive plan for an ultimately satisfying and chilled-out dive experience! I need to do a significant side-project to change the problem being solved from stock cutting to the well-known Computer Science problem of Travelling Salesman (or Travelling Diver!) so this won't be appearing anytime really soon, but it has been added as a stretch goal to the project plan!

Plan your Dive, Dive your Plan!

In 1998 I did my Master's dissertation on the subject of  'solving' the NP-Hard optimisation problem of stock cutting. My supervisor was Dr David Corne, who is now Professor and Global Goals Engineer at Heriot-Watt University in the UK. David was an amazingly supportive project supervisor and I'm really grateful for his expert guidance throughout the entire project. Checkout David's LinkedIn:

https://www.linkedin.com/in/david-corne-a478202/

The project uses the Artificial Intelligence technique of Evolutionary Algorithms, specifically the sub-class of Genetic Algorithms or GA to minimise wastage of stock eg a large sheet of plate glass when cutting out smaller panes of glass for windows...  or make that cake, for cutting small pieces of cake from a massive Mother Cake!

But, I here you ask, why is the Scuba Hacker calling out this antique C++ project on his hackaday Mercator Origins project log?

Because I want to modify the GA engine for the NP-Hard Travelling Salesman problem, or in this case the Travelling Scuba Diver problem! I'm going to use Genetic Algorithms to compute optimised Route Planning. Oh, and thanks for asking, yes this is going to run locally on the M5 Stick C Plus using the two core ESP32 microcontroller. 

I just have to decide which stick to run the code on, well I think it's obvious. I've named the three sticks after shark species: 

Mako - the navigation engine showing bearing and distance to the diver.

Tiger - The routing and UX engine that shows which target is next, with text and photo.

Lemon - Master of the internet connection, lifeline to the world and GPS message filter located in the SMB float box.

So,the answer's obvious... Tiger is going to run the Genetic Algorithm under the sea, in my hands!

I hope to have the GA optimise the following constraints;

* Include features that are flagged in the diver's wish list.

* Add a nice selection of other features to visit which fit with the dive plan depth and duration constraints.

* Dive site local weather conditions, namely air temperature.

* Dive site water temperature.

* And anything else I can think of!

I've uploaded the final write-up, project logs, code and original Win 1995 Visual Studio 5 binaries and released this all under the open source, permissive MIT licence. So you can use the code almost without exception, but you must include a copyright notice attributing the original work to me, Mark B Jones.

If you're a coder, or otherwise interested, I'd be chuffed (US English translation: very pleased!)  if you were to checkout my freshly minted github account.

https://github.com/scuba-hacker