MicroPython Forum (Archive)

I wanted to let this community know, that after several years of testing, we can finally release our micropython spectrometric platform into the open.

The problem is, all scientific instruments are proprietary. They use proprietary protocols, proprietary firmware, proprietary software. All you are left is Excel.

The solution: lets base scientific instruments on micopython platform towards a future, where every manufacturer is obliged to published their protocols.

Why? For easier automation, standardisation and extraction of data.

Who does this help? Ultimately, the community of scientists, homebrewers, open labs, small non-profits and businesses.

Lumini T - myspectral.com new open spectrometer based on micropython

Micropython spectrometer



If you are in need of such machine, please mention micropython and how you plan to use the spectrometer in your request and I can provide a very friendly price.

https://myspectral.com/#contact

It would help if you explained the relationship between the spectrometer and MicroPython as there is no obvious reference on the website. Does the device use MicroPython firmware internally? If so, is it possible for users to customise the code? Or are you simply advocating MicroPython for data processing with MP running on the host computer?

Hi Peter,

Yes, the firmware is 100% micropython now, with heavy use of the @asm decorator .
With this device I wanted to show that micropython firmware is a reliable alternative for C firmware in terms of production systems running useful, mission critical applications., as an inspiration and encouragement to other fellow micropythonistas,

Micropython on a scientific instrument offers the advantage of math, filtering and processing operations embedded on the device. A nice example is "the real-life colorpicker" calculating the R G B values out of reflected spectra (not as easy as it seems), or Normalized Difference Vegetation Index, which is interesting for plant growth and climate change researchers.

Time and the advent of 5$ MPUs have shown, that any advanced math or obscure data filtering of raw values should be done on the user side, because every user has different needs and ideas of how the raw data should be processed.
That is why we tried to reduce the functionality of the device to the bare minimum: a sensor should measure and send data over the USB cable.

I would be grateful if anyone could comment on "which groups of professionals care if a scientific device runs micropython, linux or a proprietary firmware + software?"
Fifty years of scientific instrumentation made the market appear to not care at all about customizable firmware.
Universities and industry cares more about solutions to their specific problems and customer support for getting to the target quickly...
They accept the world of nice, filtered and smoothed-out sensor data, even if it's a lie.

Any thougths?

Thank you for clarifying.

Universities and industry cares more about solutions to their specific problems and customer support for getting to the target quickly...
They accept the world of nice, filtered and smoothed-out sensor data, even if it's a lie.

Any thougths?

Yes: all due respect, but what you say here itself is almost a lie. Or at the very least a false generalization and not really a truthful view of the world. Of course universities and industry care about solutions. They want to get stuff done, not having to design each measurement device themselves. However that doesn't automatically mean they want nice smooth data and definitely doesn't mean they don't care if the result is false. I assume you have some experience leading to thinking that, well I have experience with the complete opposite both in industry and universities :]

A device using MicroPython an sich doesn't solve much when it comes to the above. Only when all that code, including whatever logic runs on the sensor and arguably the sensor design itself, is publicly available, people can be truly 100% sure hat no 'advanced math or obscure data filtering' happens to the values which are produced. Don't get me wrong: I'm all for more openness for measurement devices, even if it goes step by step, which is as far as I can tell the case for your product. But in my opinion it would be better for you to just stick to facts and tell what you're offering, and refrain from using language and non-facts making it sound more than what it really is. Any professional sees right through such commercial blabla anyway.

Many commercial spectrometers have some sort of interface that you can use to acquire data programatically, so it's not quite true that 'all you are left is Excel'.

In my last job I needed to build lab equipment to measure chemical and physical properties at low cost, so I might have been interested in this device - but to be honest we could afford something like a low-end Ocean Optics spectrophotometer for making measurements; it was the light sources and interfacing to the sample that was often a greater challenge.

I wouldn't have needed to tinker with the firmware on the device itself - I imagine this is of most interest in education, say for students learning about spectroscopic instrumentation so they could investigate the behaviour of different data processing techniques. But maybe there are other use cases I haven't considered, perhaps among hobbyist astronomers or physicists?