Your changes sound interesting.

I was wondering if anyone had any progress?

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.

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?

Sorry, What do you mean with rad.h?

Where did you get this library?

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...

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...

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

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

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).

Besides measuring distance would there be other uses for LIDAR?

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.

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!

What are some other potential uses for the LIDAR?

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

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.

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

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.

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?

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

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

?

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.

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)"

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.

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

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

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.

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

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.

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

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!

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

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

Thanks for letting me know!

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.

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.

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

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)

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

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!

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

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.

I was wondering if there are any other components needed besides the 16 you have specifically listed? I'm going to start gathering the parts a bit at a time and I don't want to miss anything. 

The parts list in the article, with the addition of the parts list from the 3d-print readme should be 90% of the stuff needed aside from wiring and miscellaneous headers and such I think.