Simple Python Fixed-Point Module port ?

[pidou46]

Hello,

What do you think about porting "Simple Fixed-Point Module" to micropython ?
https://sourceforge.net/projects/pyfixedpoint/

I think it make sense because:
- certain port (like esp8862) doesn't have floating point unit
- software floating point is less efficient than fixed point
- float point precision is limited (astronomical calculation, ect...)
- this package seems quite comprehensive, and useful for lot of projects.
- original package look quite small to me: 23ko.
- package is in active development.

My skill in python/micropython is limited, so I would like to get some advice about feasibility, usefullness, tricks, etc... before diving into this project.

[pythoncoder]

...
- software floating point is less efficient than fixed point
....

Given that MicroPython implements software floating point in C, and the fixed-point package uses Python, I'd question whether this is true in practice; it would be interesting to quantify it. Given that the package is written in Python 3.1 it should be straightforward to port it to MicroPython.

I think your aims for the project need to be defined. Are you seeking speed, RAM efficiency, or higher precision? There are certainly use cases where 32bit floats have insufficient precision, although few are relevant to embedded applications because of the limited precision of most sensor devices.

Whether the speed and RAM efficiency objectives are achievable is debatable.

[pidou46]

Thank's alot for your answer, it help me to define what I really need.

My first goal is to implement the NOAA's sun position calculation, to build an heliostat.
https://www.esrl.noaa.gov/gmd/grad/solc ... tails.html

The mechanical part of the heliostat will reach a 1 degre precision, so the software have to be able to (even higher would be needed).

Alas, this alorithm make an heavy use of real numbers (linear regression, sin/cos, power), and I guess (I not verified yet) the 1° accuracy target will not be reachable with the 32bits floating point build in micropython. "Simple Fixed-Point Module" would allow to reach 200bits precision, a bit too much though! but I think 64bits would be nice.

Speed and RAM usage, are not so critics for this case, but could be deal breakers. If calculation takes too long, precision will suffer because the sun moves at some speed and too much RAM usage simply mean no calculation at all.
But for this two last issues, I can go with an ESP32, it will not have a big consequence on the bill.

[pythoncoder]

I'd be surprised if 32 bit FP had insufficient precision. 1 degree corresponds to ~0.3%. A 32 bit float has a mantissa of 23 bits - although it may be 22 in MicroPython. Assuming the latter, that's 0.00002%. So there's a lot of room for error accumulation.

Some useful sources: "Astronomy on the Personal Computer" by Montenbruck and Pfleger, which uses algorithms from "Astronomical Algorithms" by Jean Meeus.

I've often wondered if there might be a simpler way of designing a heliostat - but I haven't looked into this in detail. The sun's azimuth moves through 360 degrees every 24 hours, so can be computed trivially to high accuracy. Its elevation can be computed from the time of day and its elevation at noon using simple geometry: the sun appears to move along a circular path in the sky which intersects the ground. The elevation at noon at a given latitude depends on the day of the year and is probably symmetrical about midsummer. So in principle a pre-computed lookup table with 182 entries should suffice.

[pidou46]

Thanks for your advices and the references you pointed me.
I have to take some time to ingest it, but I definitely adopt the concept: start simple, complexify if needed.

I think precision needed depends alot of the aim of the heliostat:
If it's just to point PV panels toward the sun, rough precision is enough.
But if it should redirect light from the sun to a fixed target, In this case precision have to be much higher, especially if the target is quite far from the heliostat.

But stop thinking, I will start to do something and I will see what I can get from it and improve it if necessary, after all it's the magic of MCU's, I don't need to make a new circuit board each time I want to change something!

[pythoncoder]

Good luck, and let us know how you get on. It's one of those problems that's interested me, but never quite sufficiently to properly analyse, let alone to actually go out and build one.

My suggestion of a 182 entry noon elevation LUT is a theoretical one per day maximum as it changes relatively slowly. You may only need (say) 26 entries based on weekly values. The error implied by a smaller LUT could readily be computed on a PC.

Another option would be a small LUT with linear interpolation. Or, taking this to its logical conclusion, perhaps the intermediate values can be calculated from a precomputed minimum and maximum. I haven't thought through how this might be done; I wonder how precisely noon elevation correlates with a cosine function? Someone out there must have done this stuff...

Choices, choices

[pidou46]

Hello pythoncoder,

Your assertion was right: It's possible to achieve sub-degree precision sun position calculation, with 30bit floating point precision from micropython, using Josh O'Brien's algorithm.
The algorithm have already been coded to python: https://stackoverflow.com/questions/870 ... -longitude

So I upload it on my WEMOS D1 MINI PRO, et voila!

It takes 2.6ko on file system.

I have runned so test to check precision:

#NOAA: 22.49, 181.19 (rounded values I guess)
#python 3.5.2: 22.448154219179965, 181.18469006927856
#micropython: 22.4479, 181.185

It's lightning fast, and I guess it's not so RAM hungry.

I would like to assess thoses last two points, I have to search forum how to do that.

Now I have to work on the mecanical side to try to acheive better precision...

It's worth to dive deeper into web research, thank's to having pointed me some sources that makes me rethink about it.

Best regards

[pythoncoder]

Interesting. From some quick tests with that code, my ideas for approximations yield errors of several degrees (at my latitude). OK for orientating a solar panel, but useless for anything needing precision.

Nothing about these astronomical calculations is as you might expect: the azimuth (here and on today's date) at noon is out by 4.7 degrees from due south, and the elevation's behaviour is not symmetrical about noon. Attempts to approximate elevation using a cosine curve showed errors of nearly 7 degrees.

In any event there is little point in coding approximations if the hardware can perform the precise calculations.