Close
0%
0%

Science Tricorder by Olympus Heavy Industries

A multi-mode scanner and data logger based on Adafruit Feather & Arduino

Similar projects worth following
This is a project I've been tinkering with for a couple years now and it actually started out as a non-functional prop. Modeled after the Tricorder devices seen in Star Trek and heavily inspired by similar projects found online. The ultimate goal is to create a functioning handheld sensor platform that can analyze, store and transmit all sensor data collected by the unit.

It’s been a hell of a journey learning how to build this thing, all started when I saw prop Tricorders at Star Trek cons in the mid ‘90s as a little kid. I’d never believe that I’d have one like this if I told past me of it…

I’ll post more as things happen

Planned features and revisions:

  • V6 (in progress) - 3d-printed chassis with a new mainboard and sensor array board assy to clean everything up and make it simpler to work on. I also need to design labelling for the door control panel and a unit label for the back of the chassis.
  • V7 - Create a new board set (mainboard, sensor assembly) and have the PCBs custom fabricated. This stage will still have the other breakout boards attach onto the mainboard and is primarilly to remove much of the wiring that needs to be soldered in place to make a unit functional.
  • V8 - Create another new board set that also removes many of the breakout boards by having the components soldered onto my custom PBCs. A few components like the Feather controller, TFT and RadiationWatch will still be breakouts since I still want a bit of flexibility (or these are too difficult to replicate).

All 3d-print files and PCB designs will be attached to the project page here.

Current scan data points:

  • Atmospheric:    Ambient temperature (averaged across 3 sensors), relative humidity, barometric pressure, Target Temp, GRIDeye temp (8x8 grid of IR thermal detectors)
  • Electromagnetic:    UV Index, IR intensity, RGB Color, Visible light intensity in Lux, UV intensity
  • Radiation:    Gamma/Xray detection
  • Gasses:       Carbon monoxide, Nitrogen dioxide, Ethanol, Hydrogen, Ammonia, Methane, Propane, Isobutane
  • Mechanical:    3-axis Accelerometer, 3-axis Digital Gyroscope, 3-axis Hall Effect Magnetometer

Currently, the Tricorder Version 6 is made up of the following:

This is now the 6th iteration of the Tricorder (the first was a prop build, not functioning), running v.o-10 code.

OHITricorder-4O.10d-forM4.7z

Current code version as of 2022-08-18, for Adafruit Feather M4

7-Zip - 12.29 kB - 08/18/2022 at 06:50

Download

OHI Science Tricorder V6 Chassis - Release ver.7z

The current version of the chassis modeling for 3d printing. This one's also updated with the correct information about the hinges.

7-Zip - 5.24 MB - 02/16/2020 at 20:55

Download

OHI Science Tricorder V6 Chassis - Rev5 NOT FINAL.7z.7z

Rough-draft for the V6 Tricorder 3d-printable chassis, a work-in-progress

7-Zip - 1.96 MB - 08/24/2019 at 04:57

Download

OHI Science Tricorder V6 Chassis - Rev3 NOT FINAL.7z

Rough-draft for the V6 Tricorder 3d-printable chassis, a work-in-progress

7-Zip - 2.55 MB - 08/08/2019 at 02:31

Download

Tricorder Legacy Code (everything up to 4o-v9.rar

This is all of the code that I've written for the various iterations of the Tricorder over the past 2 years. Covers up to 4Ov9

RAR Archive - 79.19 kB - 06/09/2018 at 20:41

Download

View all 8 files

  • 1 × Adafruit Feather M4 Express (https://www.adafruit.com/product/3857) Primary microcontroller for the unit
  • 1 × Adafruit CAP1188 (https://www.adafruit.com/product/1602) Capacitive Touch controller
  • 1 × Adafruit 2.4" TFT LCD (https://www.adafruit.com/product/2478) Display
  • 1 × Adafruit DS3231 (https://www.adafruit.com/product/3013) Real time clock with battery backup
  • 1 × Adafruit TCA9548A (https://www.adafruit.com/product/2717) i2c Multiplexer

View all 15 components

  • Back to coding

    Queadlunn08/18/2022 at 07:10 0 comments

    I've been doing more tinkering with this.

    So, when the project paused a few years ago, I'd disassembled the old v5 Tricorder to begin building the first v6. That's where I stalled out. So for now I've reassembled the v5 with a couple different parts, gotten the code moved ahead a half-step and gotten almost everything working again. The new code's attached to the project "OHITricorder-4O.10d-forM4" and it's running with publicly up-to-date libraries.


    Main hardware changes:

    • Moved from a Feather M0 to a Feather M4. This drastically changed how fast the unit ran and was nearly a drop-in replacement. The only code change needed was for the battery sense pin.
    • Changed out a few sensor breakout boards: BME280 to BMP280, other changes that are just replacement parts but the same part.

    Main code changes are:

    • Updated to get almost all functions working again (component list will be updated to reflect this)
    • Beginning to refine UI, ATM, LUM, MEC and RAD have gotten some work. ATM in particular got some changes so the Grideye can be easily moved or resized if need be. MEC has max readings displayed now.
    • Removed SD card logging for now, since I changed to the Feather M4 Express from the M0 Adalogger there's no wired-up card slot. There's one on the TFT but it needs to be wired in, this is a likely future task.

    I've also been messing with new sensors like the MLX90640 thermal camera (24x32 thermal pixels) and the M4 is plenty fast to run it but I'll need to give it it's own scan mode I think. That sensor waiting for the other ATM sensors kinda makes it a bit rough to use. I'm also looking at how to integrate a BME680 into it, replacing the BMP280. This would add humidity and basic air quality measurement. To do this it'll likely take splitting the current BMP280+MPU9250 breakout into two boards for ATM and 9DOF. Another thing to look at later on.

    I am working on the v6 body still, started a new mainboard to work on but with the heat this summer in my region, and all others :< , so that's low priority. I also plan to make a manual for the v6 (and maybe v5) as well.

    I'll update again when there's enough

  • Resuming progress

    Queadlunn07/25/2022 at 19:40 3 comments

    Hello all!


    I'm not dead and have gotten to pick this project back up after a long time.

    My current work isn't really ready to post, I'm still getting back into the swing of Arduino stuff again. Currently I'm looking at i2c-based IO expanders to consolidate some of the I/O pins on the Feather controller, maybe to allow 8-pin control of the TFT display.

    The new Tricorder is still a to-be-built, I had to scrap the main board I was working on but the sensor array is still partly assembled.

    It'll probably be a while before real updates happen but I still want to make progress on this.

    Thanks

  • Progress! Even if it's a little bit

    Queadlunn02/16/2020 at 21:02 0 comments


    Started to wire the mainboard together, even if slowly. I'm currently working on getting all of the power stuff connected up first, then I'll do the data connections. I plan on getting the mainboard working first, then working on the sensor array assembly. Slow going but it's progress!

    Thanks to Mit Balkens (https://hackaday.io/MitBalkens) for pointing out the correct hinges, I've updated the Thingiverse page and the downloadable model pack here with the correct information.

  • My current to-do list for V6

    Queadlunn11/07/2019 at 16:36 0 comments

    Bit of a lag between updates, sorry. Going to be a bit slow, probably through the end of the year right now.

    My current to-do list:

    • Finish wiring new mainboard
    • Integrate Radiation Watch board
    • Build code for new MICS-6814 gas sensor and it's power regulator (get base 3 gas types working for now, will expand later)
    • Figure out flex cable between main body and door
    • Design labelling for the door panel touchpads and a unit label

  • Good enough to ship!

    Queadlunn10/01/2019 at 04:47 0 comments

    I finally have the 3d-printable design good enough to throw onto thingiverse and here and consider it 'good enough' to fully release.


    (Here's the thingiverse link: https://www.thingiverse.com/thing:3796426 )

    I've got the files zipped up and uploaded as 'OHI Science Tricorder V6 Chassis - Release ver.7z'

    It's pretty easy to assemble, you just need a small handful of hardware besides the internal electronics. Specific parts and notes are in the Readme file.

  • Now in 3d, the Return!

    Queadlunn08/24/2019 at 05:14 0 comments

    Gotten a lot further along with the 3d shell, the primary parts are at least mostly done and I'm working on test-printing and fine-tuning stuff now.


    The big things left are getting the interface panels for the body and door further along. The main body panel needs cutouts for the TFT and controls, the door panel needs holes for the capacitive wire.


    The mainboard simply slides into the body and the body's under part (violet-colored in the 3d model image) fixes it in place. The desing's working pretty well so far but it does need a lot of tweaking for ease of use and ease of printing.

    Uploaded the current rev of the models as

    OHI Science Tricorder V6 Chassis - Rev5 NOT FINAL.7z.7z

  • And for the rough-draft

    Queadlunn08/08/2019 at 02:35 0 comments


    Added (really) rough-draft files for the V6 3d-printable chassis:
    "OHI Science Tricorder V6 Chassis - Rev3 NOT FINAL.7z"

  • Now in 3d!

    Queadlunn08/07/2019 at 06:15 0 comments

    After quite a while I've started to work on the next version of the Tricorder! I've had the hardware partially built for a while now but I'm starting to get the casing worked out in 3d so I (and anyone that wants to) can print it. It's going to take a lot of work since it's my first 3d design like this. Once I test it out and can make some changes I'll upload an STL and the original 123dx files.

  • More Progress, building Version 6

    Queadlunn01/15/2019 at 05:22 0 comments

    After a long lag I'm working on the hardware for the next version of the Tricorder!

    It's not a huge change from the Version 5 to Version 6, more of cleaning up the current design that the Version 5 ended up with. The soldering work is about half done right now, I still need to finish up the sensor array, additional sensors and the door assembly.

    The current Version 5 will have some of it's sensors moved to the V.6 (the GridEYE, 9-DOF/ATM, UV sensors) and everything else will be the same sensors in smaller breakout boards.

    Changes with the Version 6:

    • Slightly re-designed, a bit wider and shorter to allow a touch more room
    • Different sensors for:
    •      Gas sensing, got the newer version of the sensor board
    •      LUX, IR sensors replaced with same IC but smaller breakout board
    • This Feather M0 has a Packet Radio for if I make any hand scanners in the future, still unsure of that

    Ultimately I want to keep the older version working, likely remaking the casing so I can fit bulkier sensors into it (like the shape of the TNG Medical Tricorder). Since both will be using the same Feather M0 boards I also want to write one firmware that will work on both units if possible.

    Right now I'm focusing on the hardware and will resume on the code afterwords.

  • Code updated to v10, a bit of work done...

    Queadlunn06/04/2018 at 22:58 0 comments

    Small update- Got a bit of work done on the code today, expanded the Radiation scan mode's functionality. Now it shows avg pulses/second, avg pulse strength (in uSv/h) along with the last pulse detected.

    Part of this was making a timer based off of the RTC to count how long the scan mode has been on, this could be useful in other modes later on as well.

    I also got a bit further on in building a framework to allow a more interactive UI. The ultimate goal is to have the ALT button switch the button pad's functionality to that of a D-PAD along with Confirm, Cancel and Back. This'll give me a lot more to work with, like highlighting scan elements or using a menu structure. A lot of work to do on this however...


    The updated code has been attached to the project, v10.

View all 11 project logs

Enjoy this project?

Share

Discussions

josh034 wrote 10/13/2023 at 02:25 point

Have there been any updates? Has anyone had success with building one? If so, how did it go?

  Are you sure? yes | no

josh034 wrote 12/14/2022 at 00:59 point

Your changes sound interesting.

  Are you sure? yes | no

josh034 wrote 11/29/2020 at 01:56 point

I was wondering if anyone had any progress?

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 05/31/2020 at 17:50 point

I managed to run RadiationWatch and synchronize the clock correctly. Congratulations, your code works perfectly well. However, there is no room for error. I have had some problems with original components and consequently problems with address mismatch. MPU9250 Add-Ons for Ladybug + BME280 is currently not available for sales. I had to use a BME280 and an MPU92 65 separately. With that I got some conflicts but, I hope to resolve in the future. I hope you continue with your project. I really find it very promising.Thank you for your cool collaboration.

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 05/28/2020 at 16:25 point

I tried this configuration but all I get is;

Pulses / Sec: 0.000

Avg Pulse: nan

LAST GAMMA DETECTED

 n/a

The system hangs after a few minutes.
What readings do you normally observe?
How do you adjust the clock?

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 05/28/2020 at 01:46 point

Sorry, What do you mean with rad.h?

Where did you get this library?

  Are you sure? yes | no

Queadlunn wrote 05/28/2020 at 05:44 point

Sorry, "rad_subs.ino" is what I meant.

I think I found it in libraries / ArduinoPocketGeiger / RadiationWatch.h

"

class RadiationWatch
{
  public:
    /* signPin: Number of the pin to which is connected the signal wire.
     * noisePin: Number of the pin ot which is connected the noise wire. */
    RadiationWatch(byte signPin = 11, byte noisePin = 10);

"

Sorry for the lag, I haven't worked on the code for like a year and a half...

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 05/27/2020 at 18:12 point

Ok, but where this information go on the code? I did not see this in the code.

Usually would be in the line: RadiationWatch radiationWatch(11,10);

But is not there...

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 05/27/2020 at 17:09 point

Hi again,

I'm sorry to bother you again, but I have been working intensively on your project and I believe that the only thing missing is the radiation sensor. I noticed that your code for RadiationWatch is different from conventional codes. What pins on the Feather processor do you connect, Signal and Noise, from the radiation sensor. I didn't find any information about this pinout in your files or versions of your sketches.

Thanks for any help,

Cesar

  Are you sure? yes | no

Queadlunn wrote 05/27/2020 at 17:31 point

I think it's these. I can check the device tonight if it gives you trouble, at work right now.

11, RAD - signal pin
10, RAD - noise pin

  Are you sure? yes | no

Queadlunn wrote 05/27/2020 at 18:34 point

Sorry, I'll have to look at stuff in a few hours. It might be in the Rad.h file (not sure of the name).

  Are you sure? yes | no

josh034 wrote 04/21/2020 at 02:38 point

Besides measuring distance would there be other uses for LIDAR?

  Are you sure? yes | no

Mit Balkens wrote 04/18/2020 at 22:02 point

I would like your permission to use and modify your 3D model files for the V6 in my own datalogger project. What credits should I include? Thanks.

  Are you sure? yes | no

Queadlunn wrote 04/18/2020 at 22:06 point

Just link back here and/or to the Thingiverse page crediting the original design work as well. I'd love to see what others do with the chassis design! Let me know what you come up with!

Thanks for checking too!

  Are you sure? yes | no

josh034 wrote 04/05/2020 at 02:46 point

What are some other potential uses for the LIDAR?

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 03/23/2020 at 16:56 point

Hi again,

I have made some progress with your original layout and it even includes a LIDAR TF mini that is working very well. However, I have had some difficulties with the MIC6814 gas sensor. It has 3 analog outputs Co, NH3 and NO2 that according to the literature should be connected to analog inputs. According to its latest code, it looks like it should be connected to inputs A0, A1 and A2. But this is a conflict as inputs A0 and A1 are already used for the LCD and LED controller. I don't know if I understood that very well. I tried to use the A2, A3 and A5 inputs but I couldn't get readings. Did you make any changes to the sensor? what entries have you used in the latest versions?
Thank you for any help with this question.

Cesar

  Are you sure? yes | no

Queadlunn wrote 03/23/2020 at 17:03 point

The MIC6814 sensor is in-place physically but I haven't coded anything up yet since the V6 unit isn't up and running yet. That'll be my next coding chunk to work on. The Current v10 code is still using the SeeedStudio Multichannel Gas Sensor.

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 03/23/2020 at 17:20 point

I took a look at version 10 but it looks similar to the other versions with regard to the gas sensor. Everything seems to have been designed to work with the combination of analog output NH3, NO2 and CO. To use SeeedStudio Multichannel Gas Sensor it would be necessary to work with I2C bus. 
Am I making a parsing error?

Thanks,

Cesar

  Are you sure? yes | no

Queadlunn wrote 03/23/2020 at 17:28 point

The version I have hosted here (hasn't changed much) still has the code to interface with the SeeedStudio gas sensor:

-from the GAS program section:

    int A0_0 = get_addr_dta(6, 8);int A0_1 = get_addr_dta(6, 4);int A0_2 = get_addr_dta(6, 12);
    int An_0 = get_addr_dta2(1);int An_1 = get_addr_dta2(2);int An_2 = get_addr_dta2(3);
    ratio0 = (float)An_0/(float)A0_0*(1023.0-A0_0)/(1023.0-An_0);ratio1 = (float)An_1/(float)A0_1*(1023.0-A0_1)/(1023.0-An_1);ratio2 = (float)An_2/(float)A0_2*(1023.0-A0_2)/(1023.0-An_2);
    float c = 0;

The rest of the code is in the gas_subs tab/file.


  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 03/23/2020 at 17:33 point

Ok, but What means A0_0, A0_1, A0_2

This is the same that A0, A1 e A2 ?

These would be to connect CO, NH3 and NO2 ?

Is this?

  Are you sure? yes | no

Queadlunn wrote 03/23/2020 at 17:38 point

The sensor is talked to via "write_i2c(0x16, dta_test, 2);'" and "Wire.beginTransmission(addr);"

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 03/23/2020 at 17:58 point

Ok, but in this case, would not be necessary the library; <MutichannelGasSensor.h>

?

  Are you sure? yes | no

Queadlunn wrote 03/23/2020 at 18:04 point

It was earlier on, but the library wasn't working with the M0 microcontroller on the feathers I'm using. I pretty much cut as much as needed to get basic functionality out of the library and have it in the gas_subs section.

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 03/23/2020 at 19:41 point

Start to make sense, or not...
So, if I understood correctly, you created your own library to work with Grove Mutichannel Gas sensor on I2C. But if you intend to use MIC6814 without I2C bus it will be even more complicated. I think your comment next to the code makes a lot of sense;
"THIS IS ALL EVIL MAGIC, DON'T MESS WITH IT CAUSE IT'LL UNLEASH STUFF WE DON'T UNDERSTAND (don't know how this code really works lol)"

  Are you sure? yes | no

Queadlunn wrote 03/23/2020 at 20:11 point

I want to use the basic component of the sensor since then I don't have to worry about programming around the SeedStudio board and it's i2c-linked microcontroller.

It'll make the code for the Tricorder more complex, true. It'll also allow a lot more direct control of the gas sensor.

  Are you sure? yes | no

J. Ian Lindsay wrote 03/05/2020 at 19:33 point

Hey, I've used a few of the same sensors in an almost identical project. I largely re-wrote them to make them more efficient on the bus. I've also written some graphing routines for the AdaFruitGFX lib that you might find useful. Your unit looks much nicer than mine, however. ;-)

I've been toying with the idea of rolling PCBs for the sensor head. Want to collaborate on each other's projects?

https://hackaday.io/project/169475-motherflux0r

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 02/16/2020 at 17:36 point

When analyzing your photos I realized that at some point you tried to use Grove's Mutichannel_Gas. It also has the MIC 6814 sensor, but it operates only through I2C.
I also noticed from your code that at some point you tried to use the LSM303 magnetometer.
Any reason for giving up those two options?

Thanks,

Cesar

  Are you sure? yes | no

Queadlunn wrote 02/16/2020 at 20:47 point

The LSM303 was probably the Adafruit breakout that I was using earlier in the project. The component works fine but I dropped it for components that combined multiple functions to save on space, like now I'm using a MPU9250 breakout that's less than a third of the size of the LSM303 but covers a lot more of the functionality.

Somewhat likewise, the Mutichannel Gas sensor works well and has it's own logic to interpret the MIC6814 and output as I2C but it's a large board that has to be modified to work with the unit and the code is taken apart and mostly works. I'm changing to a MIC6814 breakout and a small power booster board so I can build my own code for the sensor and lower the unit's price. Those Seeedstudio sensors are pretty spendy and quite large.

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 02/11/2020 at 01:45 point

There are some numbers that you add with mx, my and mz. How did you get that numbers?

You can see a photo in:

https://ibb.co/D77QtmG

  Are you sure? yes | no

Queadlunn wrote 02/11/2020 at 02:19 point

That's looking great!

Those values were in the originating library I think. I don't remember adding that in, it's probably from the example code I used.

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 02/10/2020 at 22:05 point

I managed to do the LCD and some sensors to work. The design of the screens was very well elaborated. I have some difficulty understanding the magnetic field values. What the symbols 

<-> and ˆv mean. How did you get the MPU9250 magnetic sensor calibration. Do you have any reference on that?

Thanks,

Cesar

  Are you sure? yes | no

Queadlunn wrote 02/10/2020 at 22:28 point

The "<->" symbol is just to represent magnetic force along the Y-axis of the device, likewise the ^/V is for force along the X-axis. It's not a great way of representing it, that's one of the things I need to change when I get a chance to work on the UI again. The readings themselves are expressed in teslas (symbol: T).

As to calibration, I think the library I'm using auto-calibrates on startup but I'm not sure.

Glad to hear that it's starting to work for you though! I'm honestly thrilled to see people building their own Tricorders! If you take photos please let me see how it turns out!

  Are you sure? yes | no

Mit Balkens wrote 02/07/2020 at 23:37 point

Please note that the hinges you have listed are actually not the correct hinges. As far as I can tell you are not using the 1"L x 7/8"W Brass hinges you listed, but rather the 3/4" x 1" Butt Hinge, Black variation of the hinges listed on this page: https://www.rockler.com/butt-hinges-for-small-boxes-3-4quot-height

  Are you sure? yes | no

Queadlunn wrote 02/10/2020 at 22:30 point

That does look accurate. I'll verify the measurements and update the notes.

Thanks for letting me know!

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 02/05/2020 at 18:54 point

At first, thanks again...

I am not very familiar with the components you used in your project. I'm using some Arduino logic but some doubts still persist. I'm trying to make it work with just a few components but without much success. I am using Feather MO with DS card, CAP1188, TCA9549 and the TCS34725, SI1145 and TSL2561 sensors. Everything looks ok, but I can't get anything to appear on the TFT display. It is possible to access the serial reading of each function but apparently the sensors do not provide data, that is, they always provide the same numbers.

I wonder if there is a dependency on some other component for the set to work.
In your notes you say that you use the I2C multiplex for the BME280, RTC and Grid Eye sensors, but in your code it seems that input 2 of the multiplex works for all sensors, except GriEye which is connected to input 2. I also couldn't understand right if the ultimate goal is to work with two UV sensors, SI1145 and VEML6070 or just one of them.

I would be very grateful for any information that could help me with this start.

  Are you sure? yes | no

Queadlunn wrote 02/05/2020 at 19:16 point

Think of the i2c interface as a tree, with the M0 as the trunk with the multiplexer and all other sensors not the 3 noted are on the same level up with those 3 downstream from the multiplexer.

Aside from the BME, RTC and GridEYE; all of the other sensors have unique i2c addresses so they don't need to be downstream from the multiplexer. That's the reason for the multiplexer, those 3 components are all on 0x68 (I think), so when the code needs to look at one of those parts it'll change the multiplexer to that part and take a reading.

For the TFT, doublecheck the pins used and the code/libraries in this article, I did have to change a few things to get it all to work.

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 02/01/2020 at 21:36 point

First of all I want to thank you for your kindness for answering the questions. Sorry if I am disturbing you ...

Now, even after seeing and reviewing the photos several times and reading their text, there are still some doubts. If you can clarify them I would appreciate it very much.
1- You inserted the IC TCA9548A I2C Multiplexer in the scketch, but I don't see it in any of the photos. Why do you need it? Is there an address conflict between the sensors? How many and which sensors occupy the same SDA and SCL bus?
2- Do you have some diagram of the connections between Feathr MO and the LCD display.
Even if you don't fully remember, any information about it will be useful and will save me a lot of time. I would really like to build this instrument and eventually insert other components.

Thank you,

Cesar

  Are you sure? yes | no

Queadlunn wrote 02/02/2020 at 00:00 point

No problems!


The i2c Multiplexer is in place to switch between the GRIDeye sensor, RTC and the BME280. In the photos for the Type-5, the multiplexer is near the front of the connection board, the RTC breakout is kind of laying on top of it. In the Type-6, it's in the gap between the Feather board and the connection board.

For the TFT, this is the pinout from the Feather for the Type-5:

Pin0- RX (nc)
Pin1- TX (nc)
Pin2- n/a (no external pin)
Pin3- n/a (no external pin)
Pin4- SD card CS (no external pin)
Pin5- Touch Interrupt
Pin6- TFT_CS
Pin7- SD card CD (no external pin)
Pin8- SD Red LED (no external pin)
Pin9-

Pin10-
Pin11-
Pin12-
Pin13- Feather red LED (not used)
Pin14- TFT_DC (as A0)
Pin15- Mainboard green LED Heartbeat (as A1)
Pin16- DATA_PIN for Neopixel
Pin17-
Pin18- Speaker pin (as A4)
Pin19- RGB sensor LED control
Pin20- SDA
Pin21- SCL
Pin22- MISO (TFT, SD)
Pin23- MOSI (TFT, SD)
Pin24- SCK (TFT, SD)


  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 01/29/2020 at 23:19 point

I am an aficionado of building Tricorders. I have two personal projects that I recently built. Take a look at ;

https://nerdsdevulcano.blogspot.com

Your project caught my attention due to the degree of miniaturization. I will try to build it. Do you have any special advice ...?

Thanks,

Cesar

  Are you sure? yes | no

Queadlunn wrote 01/29/2020 at 23:23 point

As you develop the device, if you're working with many breakout boards do yourself a favor and try every layout for the mainboard & breakout boards as you can. It can save a lot of space. Finding parts that combine ICs can also save space (ie, combining multiple sensors onto one breakout).

Also, don't be afraid to drop functions related to hardware that will make the device bigger than you want. I haven't added GPS to my Tricorder yet since the antennas are relatively bulky.

Good luck with your build!

  Are you sure? yes | no

Antonio Cesar de Oliveira wrote 01/30/2020 at 12:15 point

Thank you for responding promptly. 

Your project offers a very high potential for miniaturization. You worked very well with the layout and the distribution of the components. I will try to work in your concept. I have a question about the FastLED library. The library suggested in your files is FastLED 3.1.0. However, it is generating some conflicts. In addition, when I include the zipped file, several other libraries are included, not just FastLED. On the other hand, when I try to use FastLED version 3.2.0 the conflict is minimized, but as in the first case, several other libraries are included.
This is strange because when I look at your original code it contains only FastLED. Is there anything I should know about this ...?   or I may be doing some thing wrong ...

Another issue is that the sketch uses 33% of the storage space. I don't know anything about Feather MO. What exactly does 33% mean? Does it mean that there are 67% of space available to do anything? or limited? Can the value of 33% go up when using the functions when the instrument is operational?

Thank you in advance for your collaboration ...

Cesar

  Are you sure? yes | no

Queadlunn wrote 01/30/2020 at 16:09 point

Couldn't find the 'reply' to your second comment so I hope you see this.

The library pack needs to be brought up to date. At this point I haven't really done any code work on the Tricorder in about a year so a lot can be updated or cleaned up. I remember there being some conflict with the Adafruit NeoPixel library at some point and that was the reason I switched to using the FastLED, though the actual usage for the LEDs in the device is so minimal that it could be changed out again fairly simply I think. As to FastLED's version compatabillity I can't say, it's been so long since I worked on this project's code...

For the ~33% of the memory storage space, that means the code is only using a third of the M0 microcontroller's memory, there's still a lot of space (relative to the current code) for more code to be stored for the programming.

  Are you sure? yes | no

Similar Projects

Does this project spark your interest?

Become a member to follow this project and never miss any updates