Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of 
@neilh20
Active 1 weeks, 4 days agoForum Replies Created
-
AuthorPosts
-
Wow nice to see the pictures and mechanical detail. I always find that a challenge to get integrated early – mostly because I’m doing everthing. Is it part of an open source project? souWow nice to see the pictures and mechanical detail. I always find that a challenge to get integrated early – mostly because I’m doing everthing. Is it part of an open source project? sounds like its for a specific translator/extender fiber optics to copper RS485/RS23  In looking over the Rpi PICO, while an amazing processor with program stored in a serial flash device, seemed like there wasn’t a lot of serial peripherals only 2 UARTs . At least for me that was show stopper.
I’ve just posted on a project I’ve been chipping away at https://www.envirodiy.org/topic/using-samd51-wio-terminal/ and it has the USB drivers for the drag and drop bootloader programming with the .uf2 file :), which hopefully can also be good for remote OTP (over the air programming)
@vogelrnws I wonder how its going. I see that Teensy is moving to a Teensy4.0 CortexM7
The Mayfly 1.1 is great for powering options – but it does mean understanding the tradeoffs.For an FTDI cable, for debug monitoring of the Mayfly this is what I do – https://github.com
The Mayfly 1.1 is great for powering options – but it does mean understanding the tradeoffs.For an FTDI cable, for debug monitoring of the Mayfly this is what I do – https://github.com/neilh10/ModularSensors/wiki/Test-Equipment-FTDI-cable
I also cut some pins to make it a “monitoring cable” that won’t cause a reset when the FTDI USB is plugged in to the monitoring computer. But only do that when you follow how the download works.
When programming the Mayfly I always use the USBC cable, and insure I disconnect the FTDI monitoring cable – as technically they are doing the same job and may fight (electrically speaking)
I would think +12V could also be provided to the Mayfly 1.1 Solar2 socket. All possible options – but only if you follow how the circuits work. Using Solar2 would allow the USB-c to be used with the terminal.
I use the board with a solar panel, and so it always has a LiPo 4.4Ahr battery plugged in. On the test bench with LiPo I don’t always need the external power, unless the battery needs charging. đ
Many thanks got it. I appreciate the effort and detail that goes into producing a new production run. The pogo pin connector is great and so simple.Got the .pdf – I copied the .jpg instead of
Many thanks got it. I appreciate the effort and detail that goes into producing a new production run. The pogo pin connector is great and so simple.Got the .pdf – I copied the .jpg instead of more intelligently clicking it to get the .pdf!
Just wondering if you have any thoughts on changing the Vbat  Rs to 1M / 270K for better noise immunity. It wouldn’t change the functionality, only provide a cleaner Vbat measurement . I can provide you some technical references on pop corn noise in higher value R if its of interest. https://github.com/EnviroDIY/EnviroDIY_Mayfly_Logger/issues/36
Hi @shicks, just received two Mayfly 1.1 and noticed they are rev1.1B – just wondering what the differences are from rev1.1A? đI did pull the circuit diagram from https://www.envirodiy.org/
Hi @shicks, just received two Mayfly 1.1 and noticed they are rev1.1B – just wondering what the differences are from rev1.1A? đI did pull the circuit diagram from https://www.envirodiy.org/mayfly/hardware/ however the resolution is so low, its not all readable. Just wondering if there is a pdf version. đ
I also checked https://github.com/EnviroDIY/EnviroDIY_Mayfly_Logger/tree/master/hardware but couldn’t see anything.
Many thanks
It seems to me its a working practice’s issue, repeatability and traceability- not a programming issue. From a distance, seems like you should be able to see the code in the directory that youIt seems to me its a working practice’s issue, repeatability and traceability- not a programming issue. From a distance, seems like you should be able to see the code in the directory that you are building – however you do have a unique directory structure, and if opening HicksonDeployments.code-workspace – maybe its mispointed. I open “folders”.For the working directory that compiles and downloads, my suggestion was by putting the UUIDs in a separate file ms_cfg_uuids.h -you can have the example non real UUIDs that get pushed to git.
On building your managed target system, you drop in the unqieu ms_cfg_uuds.h into the directory and then compile it.
That way there isn’t any messing around with the actual source code, and whats on a branch.
I would suggest adding a “GEOGRAPHICAL_ID” in your ms_cfg_uuids.h so the UUIDs compiled are visible, traceable and debugable.
On startup, my systems identify parts so I can manage the code – the code source, the software name, compile and then the target .
So from my debug logs, I’m currently trying to integrate the SIM7080 and was doing it previously with WiFi ESP32-wroom, I can follow what works and doesn’t
[2023-08-12 09:52:20.083] —Boot(0) Sw Build: a\src\tu_xx02.cpp Aug 12 2023 09:50:19 b’neilh20′
[2023-08-12 09:52:20.146] Sw Name: LT500/Modbus TO MMW LTE SIM7080
[2023-08-12 09:52:20.146] ModularSensors version 0.34.1-abd
[2023-08-12 09:52:20.146] TinyGSM Library version 0.11.6-aab[2023-08-12 09:52:20.225] Board: Assume Mayfly 1.1A
[2023-08-12 09:52:22.360] GEOGRAPHICAL_ID:”230723 TU-RCtest07 simRiverX Monitor”
earlier I was working on
[2023-08-04 18:19:16.580] —Boot(0) Sw Build: a\src\tu_xx02.cpp Aug 4 2023 18:14:40 b’neilh20′
[2023-08-04 18:19:16.632] Sw Name: LT500/Modbus TO MMW ESP32-wroom
[2023-08-04 18:19:16.632] ModularSensors version 0.34.1-abd
[2023-08-04 18:19:16.632] TinyGSM Library version 0.11.6-aab[2023-08-04 18:19:16.719] Board: Assume Mayfly 1.1A
[2023-08-04 18:19:18.847] GEOGRAPHICAL_ID:”230723 TU-RCtest07 simRiverX Monitor”
Well you are now into working deployment practice’s, beyond programming,So how about simplifying (I think you’re process is getting complicated . IHMO all the guideline haven’t i
Well you are now into working deployment practice’s, beyond programming,So how about simplifying (I think you’re process is getting complicated . IHMO all the guideline haven’t identified what happens when you actually have a successful program to deploy .)
Seems the question is for a successful working Mayfly logger program ….. and how to scale it  to the field.
…. you have a very good point
~~ grin ~~
Seems to me a really SIMPLE way of solving it is to put the UUIDs in an include file – and then manage the include file separately so they don’t go to github. Say “ms_cfg_uuids.h” This works if its you (and any similar programmers/colleagues) are building and deploying to the field and you can agree on labeling and where to keep the ms_cfg_uuids.h
IMHO – this is a beta development scheme. For each Mayfly it still has to be be compiled with each separate ms_cfg_uuuds.h and then downloaded to each Mayfly, and tracked on a Mayfly basis. IHMO2 this shows a weakness in EnviroDIY working practises , how to test a program to prove its successful.
If you want to deploy a number (10->??) or so loggers all the same, … what then … Deploying a number of Mayfly loggers becomes a bit more of a production line.
What I do, in my fork, (and its a big step of functionality) is put the UUIDs in a file ms_cfg.txt and then put it on the uSD. This is ideal for situations where colleagues are not programmers, but can configure a system through a built .hex and then uniquely configure the system with ms_cfg.txt
The program can be tested, and with the captured .HEX file easily deployed in multiple numbers.
Its also easy to upgrade, as its the uSD that is the key to connecting it to MMW – not the program.
I wrote about it here https://www.envirodiy.org/geographical-scaling-modularsensors/
I also write about other features that I think are missing from the mainline https://github.com/neilh10/ModularSensors
hope that is helpful đ
Hey glad to have helped!!. Whew.!Its a challenge sometime to figure out what the foundations are and build off them. I’ve had to do that before, start with a known should be working, and the
Hey glad to have helped!!. Whew.!Its a challenge sometime to figure out what the foundations are and build off them. I’ve had to do that before, start with a known should be working, and then slowly add to it to find out what came adrift.  I often use Meld Merge to compare the base directories separately from PIO.  There is a gitkraken plugin of PIO to visualize the branches – however I get lost quickly.
So your process of rebuilding from a known source is teaching moment of the challenges of source management. The next challenge is traceability – and its mostly the school of hard knocks. Sara is doing an amazing job of fixing lib versions for the main release.
You have the Mayfly version built in nicely to you platformio.ini- EnviroDIY_ModularSensors@=0.34.0
Can you imagine having your code all working, and distributed being used, and then coming back to make a modification – only to find its lost – you can’t trace what your release was. Several professional level stories of that happening – and hence why Microsoft bought github for gizzilion$
https://meldmerge.org/Â Â though I ‘m currently on an early version 3.18.3 https://download.gnome.org/binaries/win32/meld/ as some lost functionality in later releases
So good to play around with it, I asked bard.google.com a question that doesn’t have a lot written about it ..“What is the quiescent power consumption of the Bristlemouth hardware”
So good to play around with it, I asked bard.google.com a question that doesn’t have a lot written about it ..“What is the quiescent power consumption of the Bristlemouth hardware”
AND it sounds coherent – however its “hallucinating” as not a google project. The 10milliwatts its quoting is the active transmission per Mhz.
I’ve got an open question to the designers .. (https://www.bristlemouth.org/Â https://bristlemouth.discourse.group/t/what-is-the-expected-power-profile-and-quiescent-current/65)
Bard Answer:
<p data-sourcepos=”1:1-1:316″>The quiescent power consumption of the Bristlemouth hardware is 10 milliwatts (mW). This means that the hardware consumes very little power when it is not actively processing data. This makes it ideal for applications where power consumption is a critical factor, such as battery-powered devices or embedded systems.</p>
<p data-sourcepos=”3:1-3:270″>The Bristlemouth hardware is a neural network accelerator developed by Google AI. It is designed to be highly energy efficient, while still providing high performance. The quiescent power consumption of 10 mW is achieved through a number of design techniques, including:</p><ul data-sourcepos=”5:1-8:0″>
<li data-sourcepos=”5:1-5:29″>Using a low-power processor
<li data-sourcepos=”6:1-6:24″>Using low-power memory
<li data-sourcepos=”7:1-8:0″>Using a power-gating mechanism to turn off components when they are not in use<p data-sourcepos=”9:1-9:220″>The Bristlemouth hardware is a significant improvement over previous generations of neural network accelerators in terms of power efficiency. This makes it a valuable tool for developing energy-efficient AI applications.</p>
Goodluck with tracking it down :), some cyber screw come loose.Yes interesting to understand the basis of the technology. ChatGPT sounds coherent!! or as a âstochastic parrotâ, have enou
Goodluck with tracking it down :), some cyber screw come loose.Yes interesting to understand the basis of the technology. ChatGPT sounds coherent!! or as a âstochastic parrotâ, have enough people written on the problem for it to be trained to sound coherent :).
A friend said they found it helps debug xls macros!!
Like handling a “knife”, we might need to figure out how to use the “cutting edge”. Here is an article on the roots of the technology
Technology
How does ChatGPT work and do AI-powered chatbots âthinkâ like us?
The large language models behind the new chatbots are trained to predict which words are most likely to appear together â but âemergent abilitiesâ suggest they might be doing more than that25 July 2023 (newScientist)
By Edd Gent
2R59MEN ChatGPT, chatbots and AI
Illustronaut/AlamyThe current whirlwind of interest in artificial intelligence is largely down to the sudden arrival of a new generation of AI-powered chatbots capable of startlingly human-like text-based conversations. The big change came last year, when OpenAI released ChatGPT. Overnight, millions gained access to an AI producing responses that are so uncannily fluent that it has been hard not to wonder if this heralds a turning point of some sort.
There has been no shortage of hype. Microsoft researchers given early access to GPT4, the latest version of the system behind ChatGPT, argued that it has already demonstrated âsparksâ of the long-sought machine version of human intellectual ability known as artificial general intelligence (AGI). One Google engineer even went so far as to claim that one of the companyâs AIs, known as LaMDA, was sentient. The naysayers, meanwhile, insist that these AIs are nowhere near as impressive as they seem.
All of which can make it hard to know quite what you should make of the new AI chatbots. Thankfully, things quickly become clearer when you get to grips with how they work and, with that in mind, the extent to which they âthinkâ like us.
At the heart of all these chatbots is a large language model (LLM) â a statistical model, or a mathematical representation of data, that is designed to make predictions about which words are likely to appear together.
LLMs are created by feeding huge amounts of text to a class of algorithms called deep neural networks, which are loosely inspired by the brain. The models learn complex linguistic patterns by playing a simple game: the algorithm takes a passage of text, randomly masks out some words and then tries to fill in the gaps. They are, in short, trained to predict the next word. And by repeating the process over and over, they can build up sophisticated models of how language works, says Mirella Lapata at the University of Edinburgh, UK.
Recent breakthroughs are largely down to a new type of neural network invented in 2017 called a âtransformerâ, which can process data far more efficiently than previous approaches. This made it possible to train much larger models on vast tracts of text scraped from the internet. Transformer-based systems are also much better at understanding context, says Lapata. Whereas older versions could only consider a few words either side of the missing one, transformers can process much longer strings of text, meaning they can tease out more complex and subtle linguistic relationships.
What turns otherwise unwieldy statistical models into smooth-talking chatbots, meanwhile, is humans rating the output of AIs on criteria like helpfulness and fluency. This data is then used to train a separate âpreference modelâ that filters an LLMâs output. Put this together and you get what we have today, namely a text-based, computerised conversational partner often indistinguishable from a human. The fact that this was achieved using a premise as simple as next-word prediction caught a lot of people by surprise, says Tal Linzen at New York University.
But it is important to remember that the way these AIs operate almost certainly isnât the way human cognitive processes work. âThey learn in such a fundamentally different way from people that it makes it very improbable [that] they âthinkâ the same way people do,â says Linzen.
Here, the mistakes chatbots make are instructive. They are prone to confidently trumpeting falsehoods as facts, something often referred to as âhallucinationâ, because their output is entirely statistical. âIt doesnât do fact-checking,â says Lapata. âIt just generates output that is likely or plausible, but not necessarily true.â
This has led some commentators to disparage chatbots as âstochastic parrotsâ and their output as nothing more than âa blurry JPEG of the webâ. The gist of these jibes is that the new LLMs arenât as impressive as they first appear â that what they do is merely the imperfect memorisation of training data cleverly stitched back together to give the false impression of understanding.
Emergent abilities
And yet there are some indications that LLMs might be doing more than just regurgitating training data, says RaphaĂŤl Millière at Columbia University in New York. Recent research suggests that, after training for long enough, models can develop more general rules that give them new skills. âYou get this transition from memorisation to the formation of circuits inside the [neural] network that will be implementing certain algorithms or certain rules to solve the tasks,â he says.This may help to explain why, as LLMs increase in size, they often experience sudden jumps in performance on certain problems, says Millière. This phenomenon has been referred to as âemergenceâ and has led to speculation about what other unexpected capabilities AI could develop.
It is important not to get carried away. âThis term is very seductive,â says Millière. âIt evokes things like the models suddenly becoming self-aware, or things like that. Thatâs not what weâre talking about.â
Even so, Millière thinks there is a ârich middle groundâ between the naysayers and hype merchants. While these chatbots are far from replicating human cognition, in some narrow areas, they may not be so different from us. Digging into these similarities could not only advance AI, he says, but also sharpen our understanding of our own cognitive capabilities.
This story is part of a series in which we explore the most pressing questions about artificial intelligence. Read the other articles below
What generative AI really means for the economy, jobs and education | Forget human extinction â these are the real risks posed by AI today | How to use AI to make your life simpler, cheaper and more productive | The biggest scientific challenges that AI is already helping to crack | Can AI ever become conscious and how would we know if that happens? -
AuthorPosts
