Forum Rule: Always post complete source code & details to reproduce any issue!
Results 1 to 10 of 10

Thread: Teensy 3.6 as a USB webcam host (to detect alpha particles)

  1. #1
    Junior Member
    Join Date
    Jan 2019
    Posts
    18

    Teensy 3.6 as a USB webcam host (to detect alpha particles)

    Another stab in the dark for a project that is probably over my head...

    I'm thinking of building a radon detector with an old webcam (the older, the better, since a larger CMOS increases the detection chances). Think something like this, but without the "probably non-lethal" voltage multiplier...

    Detection can work on streaming data (or on a small buffer), keeping the count of pixels that are greater than a given threshold.

    The reasonable course of action would probably be to use a Linux-capable board like the Raspberry Pi, but I'd like to know if it falls within the bounds of what's possible to do with a Teensy.

    I don't know how the data is encoded over the wire. If the raw buffer is sent in RGB format, I'd need at least 640*480*3*60 =~ 55 MB/s of bandwidth.

    If it is encoded, I'd have to decode MPEG2 on the fly... Or alternatively, find the schematic for (or reverse engineer) the webcam and snoop on the sensor directly (I've read that some of them speak i2c internally).

    Brightness detection can work on one channel only, so I'd have to count a bit more than 18M Pixels per second so 9 cycles per pixel (rounding down) on a Teensy 3.6.

    Assuming the USB host route is possible, there's still the driver issue since none exists for USB Video Class peripherals.

    Could the Teensy 3.6 be amenable to one of these scenarios?

  2. #2
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,007
    No, I would say this is probably outside of the capability of Teensy 3.6.

    First, USBHost_t36 currently supports only 3 of the 4 USB transfer types. There's no low-level support for isochronous.

    Decoding a single 640x480 VGA capture would require a 921K frame buffer, or 1.22M if storing each pixel in 32 bits. Perhaps something tricky could be done to use only part of the frame, to work within the 256K RAM, but that seems like quite a lot of difficult work. And that's only if you have I frames. If the MPEG2 stream has P frames, then you'd probably need another frame buffer, and if there are B frames you'd probably need at least 3 frame buffers.

    This sort of work better for a board like Raspberry Pi, where you have large memory and a GPU that has hardware acceleration for MPEG.

  3. #3
    Junior Member
    Join Date
    Jan 2019
    Posts
    18
    Thanks Paul :-). Good point, especially re. P frames...

    Assuming I can get a raw pixel stream through I2C, could I achieve the required bandwidth?

    I'm currently leaning towards the Raspberry pi solution (with a USB cam, their own cam module has very limited software support), but I'm still curious.

  4. #4
    Senior Member PaulStoffregen's Avatar
    Join Date
    Nov 2012
    Posts
    19,007
    I2C is a low speed protocol, typically 400 kbps or 1 Mbit/sec max.

  5. #5
    Member
    Join Date
    Nov 2015
    Location
    Cold hollow VT
    Posts
    85
    If the video is in an R-G-B format or perhaps NTSC, could you take that signal and feed it into a comparitor circuit for level detection and feed the compare output into a counter to register the particle hits? Teensy 3.x has several comparitors, but I have not seen a working example on using them.

  6. #6
    Junior Member
    Join Date
    Jan 2019
    Posts
    18
    Actually, rather than processing a video feed, it would make more sense to take long exposure shots and process still images once in a while.

    I looked a bit at using the Raspberry Pi camera directly from a teensy, but it doesn't look too promising.

    The raspberry pi camera module speaks MIPI/DSI.

    DSI uses I2C for the control lane, and a fast data bus (between 1 and 4.5 Gbps not sure if it can work slower), but the protocol is closed source, and the spec is only available to MIPI members.

    The v2 camera has a DRM module that prevents it from being used with other boards :-/. The v1 cam has a larger sensor, which is nice, but I couldn't find info about it having DRM or not.

    There are also low resolution, (I've found 8x8 and 32x24 variants), low frame rate (.1 to 1 Hz) IR camera modules that only speak I2C. Any idea if their sensors could detect alpha particles? The AMG88x3,4 and MLX90640 datasheets are AFAICT mum about the tech used for the cells (and the total sensor size). I suppose that they are CMOS sensors as well, with optical filters to shut off visible light, but I'm not sure.

    Edit: the old GameBoy camera could also be an option.
    Last edited by Vam; 01-11-2019 at 11:30 AM.

  7. #7
    Member
    Join Date
    Nov 2015
    Location
    Cold hollow VT
    Posts
    85
    Quote Originally Posted by Vam View Post
    Actually, rather than processing a video feed, it would make more sense to take long exposure shots and process still images once in a while.

    There are also low resolution, (I've found 8x8 and 32x24 variants), low frame rate (.1 to 1 Hz) IR camera modules that only speak I2C. Any idea if their sensors could detect alpha particles? The AMG88x3,4 and MLX90640 datasheets are AFAICT mum about the tech used for the cells (and the total sensor size). I suppose that they are CMOS sensors as well, with optical filters to shut off visible light, but I'm not sure.
    I don't think they will work for your application. I believe they are for long wave IR (3uM to 1000uM) not the shorter wavelength just above Red (880nM to 1500nM). Their sensors are more like an array of thermo-couples, not diode junctions, so they would not produce a charge when hit by an alpha particle.

  8. #8
    Junior Member
    Join Date
    Jan 2019
    Posts
    18
    Thanks for the info. I don't have any formal training as an engineer, nor do I have any in my social circles (I'm usually the most technical person in the room), and I'm not a native English speaker, which together can make it hard to find info about a given topic (e.g. I knew about the mechanism behind thermo-couples, but I didn't know the term).

    Yup, there's this note in the MLX90640 datasheet, which agrees with your suspicion:

    IR sensors are inherently susceptible to errors caused by thermal gradients.

  9. #9
    Junior Member
    Join Date
    Jan 2019
    Posts
    18
    So the GameBoy cam looks like a good candidate. The sensor is not that small, the max exposure time is one second, and the resolution is pretty low (128x123).

    It is well documented (https://github.com/AntonioND/gbcam-rev-engineer), and there's an Arduino lib that interface with its sensor directly (https://github.com/shimniok/avr-gameboy-cam).

    A Teensy2 may thus do the trick (or the old Teensy 1 I bought ~10 years ago and left in a drawer). The above lib uses a hardcoded loop for timing, I'll probably have to tweak it for Teensy compat...

    Edit: Actually, if I want to keep the wiring simple, an AVR-based teensy is required since the sensor uses 5V signals.

  10. #10
    Junior Member
    Join Date
    Jan 2019
    Posts
    18
    So I have a few questions re. Teensy v1. I understand it isn't supported anymore (since the release of Teensyduino v1.19), and don't necessarily expect an answer, off course.

    Is the SD shield still compatible with it (assuming I use a suitable lib)? I see no reasons why not, but I'd rather be sure.

    I managed to install Teensyduino v1.18 on top of Arduino v1.0.6 and Java 6 on OS X Mojave (the recommanded v1.0.5 locks hard at when starting). I've yet to find the actual Teensy (I moved twice since I bought it). Is expected to work as well with Arduino v1.0.6?

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •