Welcome to EnviroDIY, a community for do-it-yourself environmental science and monitoring. EnviroDIY is part of 
@neilh20
6 days agoForum Replies Created
-
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.
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
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
