Meanwhile the paper versions work just fine.
It's not even different. Instead of having to interpret a couple lines you have software interpret the strip and tell you over bt on your phone. So much tech for so little.
https://aseq.substack.com/p/inside-the-lucira-check-it-covid
The best waste is the one that does not exist.
Why is there any kind of market for this?
You could do this with an analogue circuit and two LEDs.
Electronics must not be disposed with general waste, I'd imagine all Western municipalities have special recycling programs for electrical devices. Not sure if they'd be that happy to receive used covid test kits though.
We could subsidize research into biodegradables, though ...
Last I paid was 1.75 euro in DM (Germany). I remember buying them at 0.99 in LIDL.
https://www.gov.uk/order-coronavirus-rapid-lateral-flow-test...
Although it looks like you need a (free) "collect code" at the moment (because we ran out a couple of weeks back, IIRC.)
https://test-for-coronavirus.service.gov.uk/collect-lateral-...
The control line doesn't show up until the buffer solution has wicked along the test strip, so the verification is "does the line next to the letter C show up?"
The directions indicate to verify that the blue control line is present prior to adding the swab, and that the test should not be used if the blue line is not present.
You can verify this for yourself by downloading the official instructions here: https://www.fda.gov/media/141570/download
See pages 6 and 7: https://www.fda.gov/media/141570/download
https://aseq.substack.com/p/inside-the-lucira-check-it-covid
They include an STM32, but the instrument is performing an Isothermal PCR molecular test which makes the inclusion of a microcontroller a requirement.
Obviously throwing out electronics like this seems quite wasteful. But overall our society is fairly wasteful when it comes to disposable electronics.
This might explain partly why they are all sold out :(
I’m just lucky we’re a non-electronics business that shipes electronics parts. If we were an electronics company, I would seriously consider a year hiatus, or switch to software contracting for awhile.
I do wish that there was an established recycling pipeline available for them though.
I bought 50 of these 2 weeks ago. Were 3-4 euro a piece.
There are some valid reasons for tests like this to exist. To quote later on in the linked Tweet thread [1]:
BTW it's easy to say this is wasteful, and it probably is, but just like with the pregnancy test, you should consider that there's three main problems that can affect the accuracy of lateral flow tests like this:
1. inconsistent lighting
2. incorrect timing
3. human error
having a 2$ computer chip and 50 cents worth of plastic & lenses removes all those sources of error.
And making it bluetooth removes a source of e-waste! it means it doesn't need to have a screen, it can just talk to your phone.
for example, consider that a bit more than 1 in 12 people have some kind of colorblindness.
Having a computer say "POSITIVE" or "NEGATIVE" is going to be easier to see then the uncertainty of "is that stripe red? can I just not see it?"
wait, so bluetooth is cheaper than paper?
A low-tech solution would be too boring or easy.
Seems unnecessary, but if people want to buy it…
Considering that this is an article used once for a few minutes the environmental cost for production and deposition is high and society shouldn't tolerate ...
Schools and food banks can hand out free self tests so there is definitely some kind of subsidizing going on here, but in a different way.
Germany has approved a much larger number of test kits for use, per https://antigentest.bfarm.de/ords/f?p=110:100:4793921863454:::::. It was >50 as of August 2021 according to https://marginalrevolution.com/marginalrevolution/2021/08/te..., including from American companies that the FDA has not approved.
I suspect that the supply-restriction effects of the approval situation go a long way toward explaining the pricing differences...
If you just want processing power, GigaDevices has an M4 at less than $1 last I checked. Unfortunately, it wouldn't work for the design we were working on as the standby power consumption wasn't great.
Seems like you could just about accomplish the same thing with a pair of NFC tokens, a photodiode, and some transistors. Basic components. Connect one of the two NFC chips to the coil depending on how much light is reflected off the test strip. When you scanned it with your phone the activated NFC chip would respond with a URL containing a unique ID which could be interpreted by the manufacturer.
The earliest machines used a light source and color filter to try and get the signal from the finished enzyme sandwich. Then lateral-flow came along and it was up to a human to make the observation. Now we're back to the computer doing it again.
https://www.cnbc.com/video/2021/02/01/us-231m-deal-ellume-at...
Maybe I'm Elizabeth Holmsing it, but I'm thinking it could have been done for 1/50th that price while still paying people well and providing them the resources they need.
Am I missing something?
I think this is a timeframe/certainty axis more than an efficacy/cost one.
Meanwhile I'm currently in Europe and as a consumer I can buy Antigen tests for around 3 Euro per test (would be less than 2 Euro if bought in bulk). As far as I know those prices are not subsidized.
I can only compare it to FreeScale chips, but one thing that pleasantly surprised me is the flexibility in pin-assignment. Instead of the pin-mux that we'd have to do on the MK24, I could just assign pins during usb/i2c init without any limitations. The SDK is quite elaborate, although sometimes a bit difficult to use in C++.
For most users, they prefer to have the chips cheaper and spend an extra few minutes of engineer time figuring out which pins need to be hooked up to what.
I can see for smaller volume devices where engineer time dominates, and devices that you want to be really field reconfigurable, the all-to-all mux is worth it though.
https://news.ycombinator.com/item?id=29637592 (Faking a Positive Covid Test (f-secure.com))
They are cheap, last 10 years with a single battery, and do only what they need to do. Also secure. No crazy attack vectors. And easily symbolically verifiable. And I wrote tons of simulators and fuzzers for them.
Okay, I'm going to ask "Compared to whom?"
Nordic has been one of the better BLE chip manufacturers in terms of documentation, in my experience.
Most places use Keil tools directly from ARM. So, if programming these sucks, so does programming most embedded Cortex M4 chips. (No argument. Keil sucks. However, that doesn't mean that Nordic sucks any worse than anybody else).
And now you can program Nordic chips using Visual Studio Code.
All told I figured out how to make a reasonably complex chain of bluetooth devices work (largely by reading the source and comparing against old version API documentation to figure out differences), so it definitely could have been worse. But to imply that just because the documentation is BETTER than the competition that it is GOOD?
No. Its fine.
And you DO NOT have to use the Nordic SDK, there are lots of better and fully FOSS options — Apache Mynewt, libopencm3, Rust nrf-rs…
Also, it's not booting Linux at all. For these simplish one-purpose applications, you don't want the overhead and it probably would need more than the 24k or RAM onboard the nRF52810.
They could be using Zephyr though as it supports the Cortex M4 (it's a linux-like RTOS that can be heavily customised).
Embedded development is much different than what a lot of developers are used to.
But I have A product that I just did the math on. I was making a “dumb version“ that removed BLE and added two buttons. The BLE version would end up being cheaper. Of course this assumes that the Bluetooth software firmware is already completed, which for me it is.
Keep in mind that R$100 means 10% of monthly minimum wage.......
I haven't worked with CSR modules since I left that job around 2017, but the latest vendor toolchains for some chips were still on GCC 3 (~2005) at that time. We were taking bare reels and doing certification ourselves if it matters though.
The 51822 is not nearly as fun to work with as the 52s, e.g. current Apache Mynewt with NimBLE doesn't even fit into the 51's tiny flash, the 51 doesn't have systick, and so on.
They used to even ship a "No OS" SDK for the 8266, but the demand just wasn't there, FreeRTOS is pretty solid for the core competency of their product after all...
Otherwise, I agree, seems wasteful when you look at what had to happen to ship that product.
Stressfree qemu support was only for my even smaller avr targets, the 1281. But AVR is crazy compared to the Cortex-M4. We switched to arm completely, no avr's anymore. Anyway, no need for qemu or other emulators, when you can easily write simulators. You just throw in some mmaps, the simulated libc, the UART, and networking. Much better than emulators.
The key thing is to make the majority of the code portable enough to run on a PC. I find the best way to do that is to keep things data-oriented, using Plain Old Data type data structures and pure functions as much as possible. Alternative view: isolate out any device-specific pieces, like I/O into as small and simple pieces as possible. When one takes this mindset one realizes that even things that are considered as "device specific", like device drivers usually have a lot of logic that can actually be separate from the I/O. And by having a swappable I/O backend (say for I2C) one can actually test the vast majority of this logic on a computer. One should also have an implementation of the Hardware Abstraction Layer (HAL) that is "host", allowing to run on a PC, potentially with virtual inputs and outputs. This allows to run essentially all of the firmware on a PC. If one uses a embedded-friendly test framework, like Unity, then one can also run the same tests that is used on the PC on the device - to make sure that there is no difference when ran on host vs device.
Unfortunately, the code from embedded device vendors is rarely amenable to this, so that code can end up as "untestable" under this scheme. For them portability" is only considered between their own hardware devices, not to a computer. Then one has to trust that they have done their own QA. Which is usually not that great - looking at you ST HAL....
In normal times, most products not marked as EOL would be available in tens of thousands with short lead times.