Many parallel trends have advanced the open-source hardware movement over the last decade, including progress towards inexpensive and (mostly) reliable 3D printing. In keeping with the project’s ethos of accessibility, we use an Ender 3 for the rails and you can download that printable stl file directly from Tinkercad. Tinkercad is such a beginner-friendly tool that students are asked to create their own logger mounting brackets from scratch as as an exercise in the Lux/LDR calibration lab. This directly parallels our increasing use of 3D prints for installation brackets & sensor housings on the research side of the project.

One of the things that distinguishes this project from others in the open science hardware movement is that instead of constantly adding features like IOT connectivity, we have been iterating towards simplicity. Cheap, flexible, stand-alone loggers enable many teaching and research opportunities that expensive, complicated tools can not. However there are a few trade-offs with this minimalist 2-module design: Supporting only Analog & I2C sensors makes the course more manageable but loosing the DS18b20, which has served us so well over the years, does bring a tear to the eye. Removing the SD card used on previous EDU models means that memory becomes the primary constraint on run-time. The RTC’s one second alarm means this logger is not suitable for higher frequency sampling and UV exposure makes the 50ml tubes brittle after 3-4 months in full sun. Coin cell chemistry limits operation to environments that don’t go far below freezing – although it’s easy enough to run the logger on two lithium AAA‘s in series and we’ve tested those down to -15°C.

---

Jump links to the sections of this post:

• Parts for the lab kit
  • Prepare the RTC module
  • Modify & Test the Pro Mini
  • Add NTC/LDR sensors & LED indictor
  • Join the Two Modules (via I2C Bus)
  • Add Rails, Breadboards & Jumpers
• Code Overview – Setup & Main Loop
• Adding Sensors to the Logger
• General Logger Operation
• Running the Course Labs
• Other Things to Know
• Last Word

---

Parts for the lab kit:

You can find all the parts shown here on eBay and Amazon – except for the rail which needs to be printed but these days it’s relatively easy to send 3D models out to an printing service if someone at your school doesn’t already have a printer. Expect 15% of the parts from cheap suppliers like eBay or Amazon to be high drain, or simply DOA. We order three complete lab kits per student to cover defects, infant mortality, and replacement of parts damaged during the course. This is usually their first time soldering and some things will inevitably get trashed in the learning process – but that’s OK at this price point. We also order each part from three different vendors, in case one of them is selling rejects from a bad production run. The extra parts allow students to build a second or third logger later on in the course which is often needed for their final project.

After installing OS drivers for your UART, you need to select the IDE menu options:
[1] TOOLS > Board: Arduino Pro or Pro Mini
[2] TOOLS > Processor: ATmega328 (3.3v, 8mhz)
[3] TOOLS > Port: Match the COM# or /dev that appears when you connect the UART

For many years we used FT232s, but the current windows drivers will block operation if you get one of the many counterfeit chips on the market. If you do end up with one of those fakes only OLD drivers from 2015 / 2016 will get that UART working with the IDE. To avoid that whole mess, we now use Cp2102’s or Ch340’s. Some UARTs require you to cut or bridge solder pads on the back side to set the 3.3v that an 8MHz ProMini runs on. Many I2C sensor modules on the market also require this lower voltage. Avoid Pro Mini’s with the much smaller 328P-MU variant processors. They may be compatible inside the chip but the smaller solder pad separation makes the overall logger noticeably more susceptible to moisture related problems later.

---

Assembling the logger:

This e360 model is based on the 2-Module logger we released in 2022, with changes to the LED & NTC connections to facilitate various lab activities in the course. That post has many technical details about the logger that have been omitted here for brevity, so it’s a good idea to read through that extensive background material when you have time.

Prepare the RTC module:

---

Modify & Test the Pro Mini:

A Pro Mini style board continues as the heart of the logger, because they are still the cheapest low-power option for projects that don’t require heavy calculations.

---

Add the NTC/LDR Sensors & LED indictor

These components are optional, but provide opportunities for pulse width modulation and sensor calibration activities.

The way we read resistive sensors using digital pins is described in this post from 2019 although to reduce part count & soldering time in this e360 model we use the 30k internal pullup resistor on D8 as the reference value that the NTC and LDR get compared to. We have another post describing how to calibrate NTC thermistors in a classroom setting. Noise/Variation in the NTC temperature readings is ±0.015°C, so the line on a graph of rapid 1second readings is usually about 0.03°C thick. Range switching with two NTCs could also be done if the max / min resistance values of one thermistor can’t deliver the resolution you need.

You can test which leg of an LED is which color with a cr2032 coin cell using the negative side of the battery on the ground leg. The LED color channels are soldered to ProMini pins R9-B10-G11 and a 1k limit resistor is added to the D12-GND connection to allow multi-color output via the PWM commands that those pins support.

---

Join the Two Modules via the I2C Bus:

As soon as you have the two modules together: connect the logger to a UART and run an I2C bus scanning program to make sure you have joined them properly. This should report the DS3231 at address 0x68, and the 4K EEprom at 0x57.

---

Add Rails & Breadboard Jumpers:

A video covering the whole assembly process:

---

Code Overview: [posted on GitHub]

But limiting this tool to only the pre-configured sensors would completely miss the point of an open source data logger project. So we’ve tried to make the process of modifying the base-code to support different sensors as straight forward as possible. Edits are required only in the places indicated by call-out numbers on the following flow diagrams. These sections are highlighted with comments labeled: STEP1, STEP2, STEP3, etc. so you can locate them with the find function in the IDE.

Those comments are also surrounded by rows of +++PLUS+++ symbols:
//++++++++++++++++++++++++++++++++++++++++++
// STEP1 : #include libraries & Declare Variables HERE
//++++++++++++++++++++++++++++++++++++++++++

In Setup()

A UART connection is required to access the start-up menu through the serial monitor window in the IDE. This menu times-out after 8 minutes but the sequence can be re-entered at any time by closing and re-opening the serial monitor. This restarts the Pro Mini via a pulse sent from the UARTs DTR (data terminal ready) pin. The start-up menu should look similar to the screen shot below, although the options may change as new code updates get released:

The first menu option asks if you want to download data from the logger after which you can copy/paste everything from the serial window into a spreadsheet. Then, below the data tab in Excel, select Text to Columns to divide the data into separate columns at the comma separators. Or you can paste into a text editor and save a .csv file for import to other programs. While this transfer is a bit clunky, everyone already has the required cable and retrieval is driven by the logger itself. We still use the legacy 1.8.x version of the IDE, but you could also do this download with a generic serial terminal app. You can download the data without battery power once the logger is connected to a UART. However, you should only set the RTC after installing a battery, or the time will reset to 2000/01/01 00:00 when the UART is disconnected. No information is lost from the EEprom when you remove and replace a dead coin cell.

A Unix timestamp for each sensor reading is reconstructed during data retrieval by adding successive second-offsets to the first record time saved during startup. It is important that you download old data from a previous run before changing the sampling interval because the interval stored in memory is used for the calculation that reconstructs each records timestamp. This technique saves a significant amount of our limited memory and =(Unixtime/86400) + DATE(1970,1,1) converts those Unix timestamps into Excel’s date-time format. Valid sampling intervals must divide evenly into 60 and be less than 60. Short second-intervals are supported for rapid testing & debugging, but you must first enter 0 for the minutes before the seconds entry is requested. The unit will keep using the previous sampling interval until a new one is set. It helps to have a utility like Eleven Clock running so that you have HH:MM:SS displayed on your computer screen when setting the loggers clock.

Vref compensates for variations in the reference voltage inside the 328p processor. Adjusting that constant up or down by 400 raises/lowers the reported voltage by 1 millivolt. Adjust this by checking the voltage supplied by your UART with a multimeter while running the logger with #define logCurrentBattery enabled and serial output Toggled ON at a 1 second interval. Note the difference between the millivolts you actually measured and the battery voltage reported on the serial monitor and then multiply that by 400 to get the adjustment you need to make to the 1126400 value for vref. Restart and save this new number with the [ ] Change Vref menu option and repeat this procedure until the battery reading on screen matches what you are measuring with the DVM. This adjustment only needs to be done once as the number you enter is stored in the 328p EEprom for future use. Note that most loggers run fine with the default 1126400 vref although some units will shutdown early because they are under-reading. It’s rare to get two constants the same in a classroom of loggers so you can use student initials + vref as unique identifiers for each logger. If you do get a couple the same you can change the last two digits to to make unique serial numbers without affecting the readings. The battery readings have an internal resolution limit of 16 millivolts, so ±20mv is as close as you can get on screen.

After setting the time, the sampling interval, and other operating parameters, choosing [ ] START logging will require the user to enter an additional ‘start’ command. Only when that second ‘start’ confirmation is received does old data get erased by pre-loading every memory location in the EEprom with zero. A zero-trap is required on the first byte of each record because those preloaded zeros also serve as the End-Of-File markers later during download. (Note: If you leave the default LogLowestBattery enabled that is already done for you) LEDs then ‘flicker’ rapidly to indicate a synchronization delay while the logger waits to reach the first aligned sampling time so the code can progress from Setup() into the Main Loop().

In the main LOOP()

If all you do is enable sensors via defines at the start of the program you won’t have to deal with the code that stores the data. However to add a new sensor you will need to make changes to the I2C transaction that transfers those sensor readings into the EEprom (and to the sendData2Serial function that reads them back later). This involves dividing your sensor variables into 8-bit pieces and adding those bytes to the wire transfer buffer. This can be done with bit-math operations for long integers or via the lowByte & highByte macros for 16-bit integers. The general pattern when sending bytes to an I2C EEprom is:

Wire.beginTransmission(EEpromAddressonI2Cbus); // first byte in I2C buffer
Wire.write(highByte(memoryAddress)); // it takes two bytes to specify the
Wire.write(lowByte(memoryAddress)); // memory location inside the EEprom

loByte = lowByte(SensorReadingIntergerVariable);
Wire.write(loByte); // adds 1st byte of sensor data to wire buffer
hiByte = highByte(SensorReadingIntegerVariable);
Wire.write(hiByte); // adds 2nd byte of sensor data to the buffer

— add more Wire.write statements here as needed for your sensors —

The saved bytes must total of 1, 2, 4, 8 or 16 in each I2C transaction. Powers of Two byte increments are required because the # of bytes saved per sampling event must divide evenly into the physical page limit inside each EEprom, which is also a power of two in size. The code will display a warning on screen of bytesPerRecord is not a power of two.

Wire.endTransmission(); // Only when this command executes do the bytes accumulated in the wire buffer actually get sent to the EEprom.

The key insight here is that the wire library is only loading the bytes into a memory buffer until it reaches the Wire.endTransmission() command. So it does not matter how much time you spend adding (sensor variable) bytes to the transaction so long as you don’t start another I2C transaction while this one is in progress. Once that buffered data has been physically sent over the wires, the EEprom enters a self-timed writing sequence and the logger reads the rail voltage immediately after the write process begins. The only way to accurately gauge the state of a lithium battery is to check it while it is under this load.

NOTE: The data download function called in setup retrieves those separate bytes from the EEprom and concatenates them back into the original integer sensor readings for output on the serial monitor. So the sequence of operations in the sendData2Serial retrieval function must exactly match the order used in the main loop to load sensor bytes into the EEprom.

---

Adding Sensors to the Logger:

By default, the logger records the RTC temperature (#define logRTC_Temperature) at 0.25°C resolution and the battery voltage under load (#define logLowestBattery). These readings are compressed to only one byte each by scaling after subtracting a fixed ‘offset’ value. This allows about 2000 readings to be stored on the 4k (4096byte) EEprom which allows 20 days of operation at a 15-minute sampling interval.

That 4k fills more quickly if your sensors generate multiple 2-byte integers but larger 32k (AT24c256) EEproms can easily be added for longer running time. These can be found on eBay for ~$1 each and they work with the same code after you adjust the define statements for EEpromI2Caddr & EEbytesOfStorage at the start of the program.

The pullup resistors on the sensor modules can usually be left in place as the logger will operate fine with a combined parallel resistance as low as 2.2k ohms. No matter what sensor you enable, always check that the total of all bytes stored per pass through the main loop is 1,2,4,8 or 16 or you will get a repeating data error when the bytes transmitted over the I2C bus cross a physical page boundary inside the EEprom. This leads to a wrap-around which over-writes data at the beginning of the memory block. Also note that with larger EEproms you may need to slow the serial communications down to only 250k BAUD to prevent the occasional character glitch that you sometimes see with long downloads at 500k.

Perhaps the most important thing to keep in mind is that breadboards connect to the module header pins via tiny little springs which are easily jiggled loose if you bump the logger. Small beads of hot glue can be used to lock sensor modules & wires into place on the breadboard area. ALSO add another drop can help secure the Cr2032 battery in place for outdoor deployments. Some sensors can handle a momentary disconnection but most I2C sensors require full re-initialization or they will not deliver any more data after a hard knock jiggles the battery contact spring. So handle the logger gently while it’s running – no tossing them in a backpack full of books! Many students make additional no-breadboard loggers with fully soldered connections to the sensor modules if their final projects require rough handling. It’s also a good idea to put 1 gram (or 2 half-gram) silica gell desiccant packs with color indicator beads inside the body tube for outdoor deployments. A change in the indicator bead color is the only way to know if moisture is somehow seeping in, potentially causing runtime problems or early shutdown.

If you run a lab tethered to the UART for power, then your only limitation is the 30-50 milliamps that those chips normally provide. This is usually enough for environmental sensors although some GPS modules will exceed that capacity. If a high-drain GPS module or a infrared CO2 sensor is required then use those you will need one of the previous AA powered loggers from the project.

When running the logger in stand alone mode your sensors have to operate within the current limitations of the CR2032 coin cell. This means sensors should take readings below 2mA and support low-power sleep modes below 20µA (ideally < 2µA). Order 3.3v sensor modules without any regulators – otherwise the 662k LDO on most eBay sensor modules will increase logger sleep current by ~8µA due to back-feed leakage through the reg. Sensors without regulators usually have -3.3v specified in the name, so a GY-BME280-3.3v humidity sensor has no regulator, but most other BME280 modules will have regulators.

The best sensor libraries to choose should support three things: 1) one-shot readings that put the sensor into a low power sleep mode immediately after the readings 2) give you the ability to sleep the ProMini processor WHILE the sensor is generating those readings and 3) use integer mathematics for speed and a lower memory footprint. Many sensors can read at different resolutions using a technique called oversampling but creating high resolution (or low noise) readings with this method takes exponentially more power. So you want your library to let you set the sensor registers to capture only the resolution you need for your application. The library should also have some way set the I2C address to match your particular sensor module as most sensors support different addresses depending on which pin is pulled up. Always have a generic I2C bus scanning utility handy to check that the sensor is showing up on the bus at the expected address after you plug it into the breadboard (and restart the logger).

---

Logger Operation:

The logger usually draws peak currents near 3.3mA although this can be increased by sensors and OLEDs. The logger typically sleeps between 5 – 10µA with a sensor module attached. Four 5mA*30millisecond (CPU time) sensor readings per hour gives a maximum battery lifespan of about one year. So the logger is usually more limited by memory than the 100mAh available from a Cr2032. The tantalum rail-buffering capacitor only extends operating life about 20% under normal conditions, but it becomes more important with poor quality coin cells or in colder environments where the battery chemistry slows down:

The code sleeps permanently when the battery reading falls below the value defined for systemShutdownVoltage which we usually set at 2850mv because many 328p chips trigger their internal brown-out detector at 2.77v. And the $1 I2C EEprom modules you get from eBay often have an operational limit at 2.7v. If you see noisy voltage curves there’s a good chance poor battery contact is adding resistance: secure the coincell with a drop of hot glue before deployment.

When testing sleep current on a typical batch of student builds, some will seem to have anomalously high sleep currents in the 600-700µA range. Often that’s due to the RTC alarm being on (active low) which causes a constant drain through the 4k7 pullup resistor on SQW until the alarm gets turned off by the processor. Tantalum capacitors are somewhat heat sensitive, so beginners can damage them while soldering and in those cases they my turn into a short. A typical student logger should draw between 3-10µA when it is sleeping between sensor readings, and if they are consistently 10x that, replacing an overheated rail capacitor may bring that down to the expected sleep current. Also check that the ADC is disabled during sleep, as that will draw ~200µA if it is somehow left on. Occasionally you run into a ProMini clone with fake Atmel 328P chips that won’t go below ~100µA sleep no matter what you do. But even with a high 100µA sleep current logger, a new Cr2032 should run the logger for about a month measuring something like temperature, and 10 days with a high power demand sensor like the BME280. This is usually enough run time for data acquisition within your course schedule even if the high drain issue does not get resolved.

A few student loggers will still end up with hidden solder bridges that require a full rebuild. This can be emotionally traumatic for students until they realise how much easier the process goes the second time round. Once you’ve made a few, a full logger can usually be assembled in less than 1.5 hours. It’s even faster if you make them in batches so that you have multiple units for testing at the same time. Order a box of 200 cheap coin cell batteries before running a course, because if a student accidentally leaves a logger running blink (as opposed to the logger code) it will drain a battery flat in a couple of hours. This happens frequently.

Measuring tiny sleep currents in the µA range can not be done easily with cheap multimeters because they burden to whole circuit with extra resistance. So you need a special tool like the uCurrent GOLD multimeter adapter (~$75) or the Current Ranger from LowPowerLab (~$150 w screen & battery). The only commercial device for measuring tiny currents that’s remotely affordable is the AltoNovus NanoRanger, but that’s more than twice the price of the µC or the Ranger. You can also do the job with an old oscilloscope if you have that skillset. Again, sleep current is more of a diagnostic tool so you can usually run a course without measuring the sleep currents by simply running the loggers for a week between labs while recording the battery voltage. If that graph plateaus (after a week of running) near 3v and just stays there for a long time – your logger is probably sleeping at the expected 3-5µA.

---

Running the labs:

The basic two module combination in this logger (without any additional sensors) can log temperature from the RTC. This ±0.25°C resolution record enables many interesting temperature-related experiments, for example:

• Log the temperature inside your refrigerator for 24 hours to establish a baseline
• Defrost your freezer and/or clean the coils at the back of the machine
• Log the temperature again for 24 hours after the change
• Calculate the electric power saved by comparing the compressor run time (ie: while the temperature is falling) before & after the change

Note that the housing, the air inside it, and the thermal inertia of the module stack, result in ~5 to 10 minutes lag behind temperature changes outside the logger.

Try to get your students into the habit of doing a ‘fast burn’ check whenever the logger is about to be deployed: Set the logger to a 1-second interval and then run it tethered to the Uart for 20-30 seconds (with serial on) . Then restart the serial monitor window to download those few records to look at the data. This little test catches 90% of the code errors before deployment.

---

Important things to know:

Time: You need to start ordering parts at least three months ahead of time. If a part cost $1 or less, then order 5x as many of them as you think you need. Technical labs take a week to write, and another week for debugging. You can expect to spend at least an hour testing components before each lab. The actual amount of prep also depends on the capabilities of your student cohort, and years of remote classes during COVID lowered that bar a lot. Have several spare ‘known good’ loggers (that you built yourself) on hand to loan out so hardware issues don’t prevent students from progressing through the lab sequence while they trouble-shoot their own builds. Using multi-colored breadboards on those loaners makes them easy to identify later. Measuring logger sleep current with a DSO 138 scope or a Current Ranger will spot most hardware related problems early, but students don’t really get enough runtime in a single course to escape the bathtub curve of new part failures.

Money: Navigating your schools purchasing system is probably an exercise in skill, luck and patience at the best of times. Think you can push through dozens of orders for cheap electronic modules from eBay or Amazon? Fuhgeddaboudit! We have covered more than half of the material costs out of pocket since the beginning of this adventure, and you’ll hear that same story from STEM instructors everywhere. If you can convince your school to get a class set of soldering irons, Panavise Jr. 201s, multimeters, and perhaps a 3D printer with some workshop supplies, then you are doing great. Just be ready for the fact that all 3D printers require maintenance, and the reason we still use crappy Ender3V2’s is that there’s no part on them that can’t be replaced for less than $20. We bought nice multi-meters at the beginning of this adventure but they all got broken, or grew legs long before we got enough course runs with them. We now use cheap DT830’s and design the labs around it’s burden-voltage limitations. Small tools like 30-20AWG wire-strippers and side-snips should be considered consumables as few of them survive to see a second class. Cheap soldering irons can now be found for ~$5 (which is less than tip replacement on a Hakko!) and no matter which irons you get the students will run the tips dry frequently. The up side of designing a course around the minimum functional tools is that you can just give an entire set to any students who want to continue on their own after the course. That pays dividends later that are worth far more than one years budget.

All that probably sounds a bit grim, but the last thing we want is for instructors to bite off more than they can chew. Every stage in a new course project will take 2-3x longer than you initially think! So it’s a good idea to noodle with these loggers for a few months before you are ready to integrate them into your courses. Not because any of it is particularly difficult, but because it will take some time before you realize the many different ways this versatile tool can be used. Never try to teach a technical lab that you haven’t successfully done yourself a few times.

A good general approach to testing any DIY build is to check them on a doubling schedule: start with tethered tests reporting via the serial monitor, then initial stand-alone tests at 1,2,4 & 8 hours till you reach a successful overnight run. Follow this by downloads after 1,2 ,4 & 8 days. On the research side of the project, we do fast (seconds) sample-interval runs to full memory shutdown several times, over a couple of weeks of testing, before loggers are considered ready to deploy in the real world. Even then we deploy 2-3 loggers for each type of measurement to provide further guarantee of capturing the data. In addition to data integrity, smooth battery burn-down curves during these tests are an excellent predictor of logger reliability, but to use that information you need to be running several identical machines at the same time and start them all with the same fresh batteries so you can compare the graphs to each other. A summer climate station project with five to ten units running in your home or back yard is a great way to start and, if you do invest that time, it really is worth it.

Common coding errors like mishandled variables usually generate repeating patterns of errors in the data. Random processor freezing is usually hardware/timing related and the best way to spot the problematic code is to run with ‘logger progressed to Point A/B/C/etc’ comments printed to the serial monitor. In stand-alone mode you can turn on different indicator LED color patterns for different sections. Then when the processor locks up you can just look at the LEDs and know approximately where the problem occurred in your code.

---

Last Word:

Why did we spend ten years developing a DIY logger when the market is already heaving with IOT sensors transmitting to AI back-end servers? Because the only ‘learning system’ that matters to a field researcher is the one between your ears. Educational products using pre-written software are usually polished plug-and-play devices, but the last thing you want in higher education is something that black-boxes data acquisition to the point that learners are merely users. While companies boast that students can take readings without hassle and pay attention only to the essential concepts of an experiment, that has never been how things work in the real world. Trouble shooting by process-of-elimination, combined with modest repair skills often makes the difference between a fieldwork disaster and resounding success. So sanitized equipment that generates uncritically trusted numbers isn’t compatible with problem-based learning. Another contrast is the sense of ownership & accomplishment that becomes clear when you realize how many students gave their loggers names and displayed them proudly in their dorm after the course. That’s not something you can buy off a shelf.

---

References & Links:
Waterproofing your Electronics Project
Successful field measurements when logging stream temperatures
Examples of soil temperature profiles from Iowa Environmental Mesonet
Oregon Embedded Battery Life Calculator & our Cr2032 battery tests
A practical method for calibrating NTC thermistors
Winners of the Molex Experimenting with Thermistors design challenge
Sensor Response Time Calculator (τ 63.2%)
Calibrating a BH1750 Lux Sensor to Measure PAR
How to Normalize a Set of BMP280 Pressure Sensors
How to test and Calibrate Humidity Sensors (RH sensors are not reliable outdoors)
Setting Accurate Logger time with a GPS & Calibrating your RTC

And: We made a Classroom Starter Kit part list back in 2016 when we were still teaching with UNOs and a post of Ideas for your Arduino STEM Curriculum. Those posts are now terribly out of date, but probably still worth a read to give you a sense of things you might want to think about when getting a new course off the ground. Those old lists also predate our adoption of 3D printing, so I will try post updated versions soon. The bottom line is that if you are going to own a 3D printer you should expect to have to completely tear down the print head and rebuild it once or twice per year. While they are the bottom of the market in terms of noise & speed, every possible repair for old Enders is cheap and relatively easy with all the how-to videos on YouTube. Those videos are your manual because Creality broke the cost barrier to mass market adoption by shipping products that were only 90% finished, with bad documentation, and then simply waiting for the open source hardware community to come up with the needed bug-fixes and performance improvements. X/Y models are more robust than bed-slingers, but our Ender 3v2’s have been reliable workhorses provided you stick to PLA filament. If you want a fast turn-key solution then your best option is one of the Bambu Labs printers like the A1 because they are essentially plug&play appliances. But if you enjoy tinkering as a way of learning, that’s Ender’s bread & butter. A bed level touch sensor is -by far- the best way to get that critical ‘first layer’ of your print to stick to the build plate and the E3V2 upgraded with a CRtouch & flashed to MriscoC is an OK beginners rig. Our local computer stores always seem to brand new 3v2’s for about $100 as a new customer deal but these days I buy cheap ‘for parts’ Ender5 S1’s from eBay for about that price and fix them up because 120mm/s is about the minimum speed I have the patience for. Now that multi-color machines are popular, what used to be high-end single-color machines are being discounted heavily so even brand new E5S1’s are selling for about $200 in 2025 if you look around. Having two printers means a jam doesn’t bring production to halt just before fieldwork, and by the time you get three printers the speed issues disappear and you can dedicate machines to different filaments. Keep in mind that no matter how fast your printer is capable of moving the print head, materials like TPU and PETG will still force you to print at much slower rates if you want clean prints with tight tolerances. To reduce noise, I usually put the printer onto a grey 16x16inch cement paver with some foam or squash ball feet under it.

Avoid shiny or multi-color silk filaments for functional prints as they are generally more brittle and crack easily. Prints also get more brittle as they absorb humidity from the air. If that happens, cyanoacrylate glue + baking soda can be used for quick field repairs. It’s worth the extra buck or two to get filaments labeled as PLA pro as they usually have better durability in trade for slightly higher printing temperature (as long as the company was not lying about their formulation). I use a food dehydrator I bought for $10 from a local charity shop to dry out my PLA or PETG filaments if they have been open for more than a month. Really hygroscopic filaments (like PVA, TPU or Nylon) have to be dried overnight before every single print. Most machines work fine with the defaults, but you can get great prints out of any printer provided the bed is leveled, the e-steps & flow are calibrated, and the slicer settings are tuned for the filament you are using. If you are using Cura there is a plugin called AutoTowers Generator that makes special test prints. You print a set of those (for temperature, flow rate and then retraction) and set your slicer settings to match the place on the tower where the print looks best. You may have to do this for each brand of filament as they can have quite different properties. I rarely use filaments that cost more than $15/kg roll because functional prints don’t have to be that pretty and you will be tweaking each design at least 10 times before you iterate that new idea to perfection. I stock up on basic black/white/grey on Amazon sale days for only $10/roll. Once you get the hang of it, most designs can use 45° angles and sequential bridging to print without any supports. Conformal coating or a layer of clear nail polish prevents marker ink from bleeding into the print layers when you number your deployment stations.

As a researcher, becoming functional with Tinkercad and 3D printing is a better investment of your time than learning how to design custom PCBs because it solves a much larger number of physical issues related to unique experiments and deployment conditions. That said, it’s not usually worth your time to design things from scratch if you can buy them off the shelf. So people get into 3D printing because what they need does not exist or is outrageously expensive for what it does. All FDM prints are porous to some extent because air bubbles get trapped between the lines when they are laid down – so they are not truly waterproof like injection molded parts unless you add extra treatment steps. UV-resistant clear coating sprays are a good idea for outdoor deployment. I don’t have much use for multi-color printing, but when they advance that to supporting multiple materials I will be interested because being able to print at TPU gasket inside a PETG housing would be quite useful.

If you are just getting started and looking for something to learn the ropes you can find useful add-ons to your printer on thingyverse or, you could try organizing your workspace with the Gridfinity system from Zack Freedman. You will also find lots of handy printable tools out there for your lab bench searching with the meta-engines like Yeggi or STLfinder. A final word of warning: this hobby always starts with one printer… then two… then… don’t tell your partner how much it cost.