Big Trouble with LittleFs

Full track recording is one of the nice-to-have functionalities of the CUBEs. The problem here, however, is that the SD card which is used to keep the data gets easily damaged as data flushes to the FAT filesystem cause considerably high wear, especially in the file allocation table (file size & last modification time). The latter could be avoided by disabling the last file updates time in code. Still, the file size and number of sectors allocated is updated every time a block is added to the file. Keeping the data in memory and flushing in larger chunks may seem to be obvious solution, but when taking the MCU’s RAM size of 20kB (while a lot is already allocated) and FAT sector size of 512B into consideration, one can see there is not much maneuvering space.

Hence, the LittleFS seemed to be the perfect solution. Power resilience and wear leveling make it an exact fit for this troubles until you realize its code base is over 4000 lines and make it considerably spacious after compilation – 8KB, even when forcing size optimisation and omitting unused routines in the compiler settings.

In combination with the pending problem of the rest of my code being already a tight fit into the F103CB’s 128kB FLASH (there is also a custom 8kB bluetooth boot loader for firmware updates), the size of resulting binary with LittleFS included has reached the point it does not fit into the program memory space.

Well, what now? There are two options. The first one is to use an F103 MCU with more FLASH like the STM32F103RB. The catch here, are its 64 pins on the larger footprint while the current PCBs is layed-out only for 48 pins of the CB variant. And as I don’t really want to be redesigning the PCB at this moment another option seem to be quite feasible – to replace the MCU with another one. The nice thing with STM’s controllers is they tend to have compatible pinouts. And as I already have some supply of STM32F030CCs in my drawer (and have big plans with that one in another project), this one seem to be the right fit for replacement. It’s got 256kB of FLASH and 32kB of RAM (comparing to 20kB of the F103CB). Some of the libraries I use will have to be extended to support the F030’s architecture (ARM Cortex M0 vs. M3, the buses and peripherals are organised in a bit different manner) but it would keep the footprint small while opening the opportunities for further development! πŸ™‚

But as things never can go easy, there is another problem. In the recent months the Standard Periperal Libraries (SPL) are for some reason not available for download for the System Workbench for STM32 (sw4stm32) and I cannot make it work even when downloaded them manually from the STM’s web. I have reported the problem on the openstm32.org forum already in two posts (the first, the second) with no success so far. Even the SPL firmware for the F103 doesn’t work now for me.

(Edit) I’ve eventually found a workaround. It’s crude, but it does the job! πŸ™‚

CUBE3s Available for Ordering

Few weeks ago I had silently added the Choose & Buy option in the menu above but somehow forgot to announce that aloud. I have just noticed mu last post is from April and since that time this site looks kinda dead. But I am telling you – it is NOT! πŸ™‚

We have made twenty five more Cubes (yes another 25!) and those are now being shipped around the world! I wanted to speed up the production process a bit, hence this batch is partially machine-populated. This helped significantly but not as much as I hoped – mainly due to my mistrust and doubts – which were, again, completely unnecessary as it turned out in the lucky end.

I plan to write a longer post about this endeavor later on – a story about going to small production without any prior experience. Yet, the season is on, let’s do some soaring first! πŸ™‚

A LOT of Cubes

Long time no see, right? Over the last month I have been busy with some modifications on the PCB (oh snap!) as well as parts ordering, sorting, reordering missing ones, soldering and finally enclosure printing in order to finish a bit larger order of these little sweet boxes.

As thorough testing is part of the process I have been driving this load around the county for some time. I only wonder what the passersby might have been thinking.

All units passed with flying colours and hence could be nested into their new home.

Do you love it as much as I do? Great job, Ibisek, great job indeed! πŸ™‚

First Two CUBE3s Are Out!

The great day on which two units equipped with three-axis accelerometers and new flight-logbook recording feature have finally reached their happy owners. The first one is about to start its fruitful career in a Piper 28 while the second found its home in an (to me) odd-looking Morane-Saulnier MS.880 πŸ™‚

Despite their confusing micro-USB connector they can be powered directly from the 12V power rail (4 to 15V to be exact). Naturally they sport all the sweet features like the previous development stages – here I’d like to highlight bluetooth communication delivering surrounding traffic information, over-the-air updates and logbook downloads directly to an Android-based phone or tablet (the app will come later, I promise πŸ˜‰ ).

Currently I’m experimenting with various models of the enclosure: from the top – slim (for simple micro USB-power, 17mm of height), regular (RJ45, 20mm) and finally a thick boxes for the battery-powered variant (24mm).

Back on Track

Are you familiar with saying “I have a friend who has a friend..?”

I have a friend who has a friend who can solder.. and I mean really, really well! Using a microscope in combination infra-heating chamber he managed to solder that tiny 3x3mm chip with 24 (no-)legs and it works in all three specimen he produced. I have never seen such a great and clean job before! Awesome!!

It’s so delightful! Just look at that beauty!

This also means we could verify the PCB design is correct and thus we can start truly “massive” production. Even after some had indicated they have no use for such a lovely accelerometer and wish the board to be unpopulated in that spot (complications, grrrr!) But for the other not-so-blindfolded individuals I presume this would be a nice to have extended functionality πŸ™‚

Stay tuned as further detail on OGN CUBE3s build will come shortly!

Soldering Hell

Soldering of the U8 chip went exactly as anticipated. Having spent already more than 10 hours and damaged three chips this job seems to be unreasonably hard.

The QFN24 package is just 3x3mm with 0.2mm legs. Actually they are not legs, there are L-shaped surfaces below and partially on the side of the chip. I’ve already discovered the right amount of soldering paste, the chip seems to be right in place and all the visible side surfaces seem to be soldered just right only the chip does not respond. The design seems to be right and I measured the contacts to be just fine on both sides the chip and the micro. It is still possible I had it overheated during the soldering as I was getting pretty upset at the end of the day..

The rest of the board seems the work as intended, especially the new switched DC-DC step-down converter makes me particularly happy. You can also spot the new super-capacitor (C10) backing up power for the GPS receiver.

There are three different designs on the board – the 12V-powered model “A” with micro USB connector (as you can see here), battery powered model “B” (depending on which parts are populated) charged by the same uUSB connector and model “A” with RJ45 socket for which a large cutout in place of the uUSB (P7) is made (that needs to be made as a separate PCB).

Right – now just to find a way how (or someone) to solder that bloody U8 and we can fire up the wheels of a production line! πŸ™‚

OGN CUBE 3 Prototype 1 PCBs

It is mid January I finally got the message they finished my PCBs so without any thought of hesitation I left my work in mid day and I hurried to pick them up right away.

Top view
Bottom view

To be honest I am a bit frightened of the U8. Obviously not the chip itself but of the soldering fun (I really mean hell) to be expected..

OGN CUBE 3 Prototype 1

Over the Xmas “break” I finally saved some time to amend the schematic and add two new blocks. The first one is switched DC supply to eventually replace the linear regulator and thus save a lot of battery juice when powering the tracker directly from 12V on-board battery.

The second improvement or actually a new feature is footprint for the promised accelerometer / gyroscope on board. There are two solderable options – MPU-6500 or MPU-9250. The guys from Invensense did a reasonable job to put those in compatible package with only one extra jumper to be solder-bridged on the PCB when having populated the latter.

A third tiny gem is a miniature supercap on the backup input of the GPS module to retain last known location (for approximately 12 hours) in case of power outage. It shall be significantly faster than from a cold start!

By routing the board I pushed again my capabilities way farther while putting in all the additional parts and saving space on the board as there were so many of them and the remaining free space was so scarce. Groovy!

A little thing still the bugs me a bit. It is mainly the MPUs are marked as “not recommended for new development” on Arrow and Farnell but hopefully will be still available for some time. And during that time the future will show whether this part is of any use and advantage or completely none πŸ˜‰

The prototype board has been sent to production on 27th December and shall be finished in mid January. I presume a week later I should know if there are any problems on the board and the design will need some additional rework or not. I hope for the better, of course.

And then, finally, I will have to find someone who will help to manufacture the units because as I said last year – I will never solder so many boars by hand again! πŸ™‚

Data Logging Fully Operational

After  a long break (seasonal, really) I am finally back with yet another good news ~ I have finally saved time and devoted rainy afternoons and many sleepless nights to the long-promised feature – the data logging.

It had had been such a long run mainly due to my initial intention the code must be original, based on “pure” STL and every part must be clearly explainable, no black boxes and fuzzy libraries. Hence, to make the FAT live on the uSD connected via SPI  was  anyhow close to a piece of cake (as obviously is for the other folks our there). There were virtually no clues how to bend Chan’s FatFS library to my needs. Until after a  considerably long desperate days of hopeless searching I have discovered this site which old version contains a treasure box in form of these two blog entries that really made my day. Cheers buddy, whoever you are!! πŸ™‚

After having mastered the FatFS operations there was another riddle to solve – the format in which to store the data. Initially, the .IGC seemed to be a natural choice (and also many suggested so) but as we need to store some more information than the IGC format supports (e.g. acceleration data), this was not the right one. Additionally, the IGC seems to be rather verbose and since there is no plan or vision to make the OGN Cubes certified FAI recorder we do not need the record to be signed and processed in the traditional way. On the contrary, human readability of the recorded files would be beneficial.

For that reason we came to the conclusion a simple CSV file with meaningful header could be the best choice. It can be easily read by a spreadsheet processor, converted to various formats (GPX for example) and the resulting files are of reasonable size also in case of considerably long flights.

You can see an example of selected recording lines right here:

$OGNR;HHMMSS;gpsFix;pressure[Pa];lat;lon;gpsAlt[m];gpsSpeed[m/s];gpsTrackCourse[deg];ax;ay;az*CRC
$OGNR;112332;3;92884;49.860138;17.613463;727;56.4;327.2;0.222;-0.886;1.370*2a
$OGNR;112341;3;92917;49.864000;17.609517;726;57.7;326.6;0.598;-0.640;1.093*28
$OGNR;113317;3;91468;49.898227;17.543775;852;46.2;246.3;0.592;-1.177;1.069*25
$OGNR;114233;3;93324;49.815882;17.234948;686;52.5;78.9;-0.697;-1.389;1.520*3f

Each flight record starts with a header describing consequent lines. There can be multiple flights in one file which are separated by a header. Flight start and finish are controlled by certain conditions in the tracker’s code (ground speed & interval of inactivity). The data is stored on the SD card in single file per day with its filename in formatted as 20181022.ogn (i.e. YYYYMMDD.ogn).

As the logging feature is finally in its mature state can been released to the wild. Those of you who have a tracker box with the uSD card slot present will receive firmware update shortly. The update procedure is  as described in the leaflet. You will need to use the firmwareLoader to upload the new binary to the unit from your laptop via bluetooth.

The work on further releases is still not done, however. In the upcoming weeks and months the plan is to implement:

  • Android app to download and flash the firmware updates seamlessly,
  • to download the flight logs from the unit using the same app so we don’t need to remove and put back the tiny uSD card every time,
  • to integrate the accelerometer to the PCB (there is still a lot of work, experimenting and decisions to be made),
  • and finally, one day, to add the you-know-whose protocol support.

And that’s all for this time! πŸ™‚

Tale of the First Twenty Magic Boxes

May turned into its second half when a package with so much expected PCBs finally arrived from Apama (a local manufacturer in Brno). During the following weeks they gradually migrated from one box to other, then yet another and back until they grew up and matured to their shiny functioning state.

This is the story how it all happened.

Breaking up the frame into separate little boards was a pure pleasure.

Followed a thorough visual inspection of each piece from its top and bottom side. You know, when electric check is not enough..

First populated power source & MCU. Bringing it to life and also first test of correct battery operation on the second revision of the PCB.

Soldering a single MCU is a piece of cake. Five is still OK. But TWENTY?!

Adding microUSB and SMA connectors.

All SMDs are finally on board – let’s start with modules!

Populating pressure sensors means to solder only 20 x 6 = 120 legs. Easy! πŸ™‚

Bluetooth modules ready for soldering as the next; they go to the bottom side.

GPS and radio modules.

And first fully populated OGN tracker is alive! Hooray! πŸ™‚

They are starting to pile up..

.. till they are everywhere!

Each and every antenna was carefully packed in a tiny plastic bag. Unpack one is a short operation, but twenty of them took some time.

Aren’t they cute? πŸ™‚

Every tracker comes with a tiny but still powerful battery (nothing for the drumming rabbits). The fella in the shop was looking a bit suspiciously when I was requesting 22 of those, asking what do I need so many Nokia phones for.. B-)

And seriously,