Integrate useful Buoy sensors into Faraday.

[kb1lqd]

Purchase and/or design sensor board(s) that integrate into Faraday's ADC's or SPI/I2C interface for use on the Buoy mission. Educational documentation should be created at a system level to show how Faraday integrates with sensors.

High Level Plan

Plan 1

• Integrate I2C sensors bit-banging I2C through GPIO pins

This keeps Faraday in a high use situation but low power setup. It utilizes Faraday as a "Smart Node".

Pro's

• Small and compact
• Low power
• Leverages Faraday's smart node abilities

Con's

• Needs to support I2C likely through a bit-banged interface due to lack of available ports
• All I2C libraries must be written.

Plan 2

• Adapter analog sensors to ADC's, avoid re-scaling if possible

Pro's

• I2C and other interfaces have supported libraries and ports - Easy integration
  • https://learn.sparkfun.com/tutorials/raspberry-pi-spi-and-i2c-tutorial
• Can write Python scripts to query and format data
• Steps the Rpi computing resources into the telemetry feed and control aspects
  • Could use oppurtunity to make RPi telemetry stream server program for "Faraday" ecosystem

Con's

• Needs lots more power / bigger battery
• Larger setup
• Relegates Faraday to mostly a "modem" use and utlitzing it's GPS
  • Not necessarily a bad thing, this was a longer term goal anyways to offload processing to Rpi for higher data throughput

Analog

• Wind Speed
  • https://www.adafruit.com/product/1733 - 0.4V - 2V output
  • https://media.digikey.com/pdf/Data%20Sheets/Adafruit%20PDFs/1733_Web.pdf
  • Datasheet is in Chinese... Vendor states: "To use, connect the black wire to power and signal ground, the brown wire to 7-24VDC (we used 9V with success) and measure the analog voltage on the blue wire. The voltage will range from 0.4V (0 m/s wind) up to 2.0V (for 32.4m/s wind speed)."
• Temperature
  • TM36 and custom harness/epoxy coating (
    • Can likely get away without any drivers/4-20mA
• Barometric Pressure
  • https://cdn-shop.adafruit.com/datasheets/BST-BMP180-DS000-09.pdf
• Wind Direction
  • JL-FS2 Wind Direction - 4-20mA / 0-5V
• Compass (To determine wind direction absolute direction)
  • KMY_KMZ Analog Magnetic Field Sensor
  • http://www.te.com/commerce/DocumentDelivery/DDEController?Action=srchrtrv&DocNm=KMY_KMZ&DocType=Data+Sheet&DocLang=English

Work Needed

• Design analog scaling/driver circuitry PCBA (#265)

  • Scale voltage window between 0V-VREF of CC430
    • Wind Speed (0.4V-2V)
    • Wind Direction (0V-5V option)

• Support digital interfaces (firmware)

  • I2C Faraday port access and code
    • Compass
    • Barometer/Temp/Altitude BMP180

• Integrate hardware and wiring

Integrating I2C Sensors

https://learn.sparkfun.com/tutorials/i2c

Using the Faraday headers I'll need to wire out:

• GND
• SDA (Data)
• SCL (Clock)
• OPTIONAL
  • Power 5V or 3.3V to sensor(s)

I'll also need to supply pull-up resistors.

I/O Pin - Bit Bang

Due to the need/want to avoid sharing the SPI/I2C port assigned to the SRAM IC (having to switch modes and that the SRAM is used for everything!) I'm going to have to use a GPIO and bit bang. Preferenble this GPIO will have interrupt capability to receive data from the slave(s) and the only externally available pin to do is is ANALOG 2! This pin has an interrupt capability and doesn't have an RC filter to remove!

I2C Bit- Banging Pinout

SDA = A2 = P2_5 SCL = D8 = P5_2

GND = GND Pin

Firmware - I2C

• SPI HAL: https://github.com/FaradayRF/Faraday-Firmware/blob/master/Faraday_HAL/SPI.c
• SRAM: https://github.com/FaradayRF/Faraday-Firmware/blob/master/SRAM/SRAM.c

We need to:

• Add I2C support to HAL
• Add swappable SPI I2C Mode
  • May be difficult because SRAM is used for a TON of things around Faraday. May need to make completely blocking as possible.
  • Bit Bang I2C?
  • https://gist.github.com/ksvbka/fec1f28ce40c276334fb @kb1lqc This may actually solve a lot of timing issues and SRAM...
    • This is polling based...
  • http://www.ti.com/lit/an/slaa703/slaa703.pdf
    • TI supplied firmware! May need some updates. Needs a timer...

Analog Voltage Sensing

Voltage Reference

https://github.com/FaradayRF/Faraday-Firmware/blob/master/Faraday_Init.c#L413 and https://github.com/FaradayRF/Faraday-Firmware/blob/master/Faraday_Init.c#L445 initialize Faraday to use the CC430 internal 2.5V reference for the ADC inputs.

Apendix

TM36 Remote Sensing Datasheet

JL-FS2 Wind Sensor

• 

  • 

Barometric Pressure

We're going to need a protective case and PCB for this but NOT sealed.

Possible ranges only vary a few kPa so it might be useful to zoom and scale into those regions?

I2C Hardware Support CC430

We will avoid using this functionality because the priority to share this port with the SPI SRAM is critical. Bit banging I2C or switching to RPi for ease of use OK.

The I2C pins routed to the header on Faraday are silkscreen with the SPI option of MOSI and MISO. Changing the configuration of the hardware support for those pins and using the 3 signals needed (SDA/SCL/GND)

We'll be using the USCIBx bus and need to enable I2C mode. USCI_Bx is IN USE for the SRAM in SPI mode so we'll need to share with the sensors._

Setup I2C Raspberry Pi

• http://www.raspberry-projects.com/pi/pi-operating-systems/raspbian/io-pins-raspbian/i2c-pins
• http://www.raspberry-projects.com/pi/programming-in-python/i2c-programming-in-python/using-the-i2c-interface-2

[kb1lqc]

Sounds good. You sure we want to create conditioning boards for 4-20mA or 0-5V? I take it this is the lesser of the evils for available sensor products that are mostly off the shelf?

[kb1lqd]

Well @kb1lqc I'd prefer 0-5V scaling to 0V to VREF as it's simpler. We could try to find all I2C sensors too but I'm a little worried on getting I2C going... just from a gotcha's and such standpoint.

[kb1lqc]

OK @kb1lqd, at what point does interfacing I2C just buy us a big bang for the buck? Adding on conditioning hardware is a tad much if there are better and more convenient options in I2C.

[kb1lqd]

OK well let me see what I can find.

[kb1lqd]

@kb1lqc I recall my largest concern about the I2C:

We'll be using the USCI_Bx bus and need to enable I2C mode. USCI_Bx is IN USE for the SRAM in SPI mode so we'll need to share with the sensors.

So we'll need to swap between SPI and I2C and while I2C is in use we can't use the SRAM.

[kb1lqd]

@kb1lqc Are we planned out enough here to pull the trigger on buying sensors?

[kb1lqc]

@kb1lqd what about the DS28E17 from Maxim IC for 1 wire to I2C? I bet there are breakout boards for this.

[kb1lqc]

Possibly useful cheap board for 1-wire to I2C: http://modtronix.com/im1wp-tbb.html more expensive: https://www.tindie.com/products/closedcube/ds2482-800-i2c-to-8-channel-1-wire-breakout-board/

[kb1lqc]

Also @kb1lqd these Blue Robotics cable penetrators look awesome!

http://bluerobotics.com/store/connectors/penetrator-10-25-a/

[kb1lqc]

OK looking at the sensors I have a few comments @kb1lqd

• We're initially using APRS-IS (at this time) to transfer data onto the internet which only has allocations for five telemetry channels
• We do save our own data and have it all but this is something to consider for the first buoy
• currently we use the internal 2.41V reference which isn't terribly good (1.5% I believe). Is there actually a 2.5V internal reference? Do we want an external reference?
• For the 0-2V signals I may just say don't buffer them, is it worth full dynamic range of 2.41V to add that many more op-amps? I supposed if we have an external board with one op-amp then what is a few more...
• I am actually not sure we want to use 0-5V. If my memory serves me well it can be a pain in the butt to scale down from 0-5V to 0-2.41V. Probably easy with a voltage divider and op-amp buffers but we could easily see more noise here. I wonder if 4-20mA works better here. It's more power but about the same complexity if we are buffering (current sense amplifier instead of buffer amp). It's worth thinking more about.

[kb1lqc]

Overall I have some comments on general sensors

• We probably shouldn't go overboard on the pure number of sensor channels. Can you put some thought into why we would want each channel? Maybe compare against other buoys. We should focus on providing the minimum in useful design for this first one. Also check out this project which has some good ideas.

[kb1lqc]

@kb1lqd check out the NOAA buoys: http://tao.ndbc.noaa.gov/proj_overview/sensors_ndbc.shtml

You can actually search some of their sensors. Pricey (I mean... it probably costs a LOT in fuel and labor to send a boat out to put the expensive buoy in these places anyways!).

*Wind Sensor

• Air Temperature

Not sure how useful but it's interesting.

[kb1lqc]

Oh neat, here are some more specifications for buoys

Drifter Moored

[kb1lqd]

I Soldered jumpers to the pins on Faraday to allow bit-banged I2C. Note that I needed to use AD2 as a GPIO because it is the only GPIO port left with interrupt capability externally.

I also hooked up the RPI to I2C for both basestation I2C ADC to sense shutdown voltage and if it is needed to just use for I2C sensors.

@kb1lqc will be interested.

[kb1lqd]

@kb1lqc

I just used adafruits library and instructions for the ADS1015 ADC using I2C with the Rpi and I'm reading ADC values!

This is useful for auto-shutdown and basestation temps but also shows work system/python I2C ADC interaction.

I'll work on Faraday's I2C bitbang tommorow...

[kb1lqd]

@kb1lqc (Read all, especially near bottom)

I found http://www.ti.com/lit/an/slaa703/slaa703.pdf which the ZIP download has usable code it seems. This does need a timer that I may not have right now.

My setup took me a while after getting home today and now code composer isn't seeing Faraday... I may try again not at 11PM.

I'm wondering how long I give tying to get Faraday to bit bang I2C versus just use the working Rpi I2C? I know that keeping the smart modem capability is ideal but wondering how much, at least for now to keep things moving.

Faraday Base I2C

• Port I2C bit bang code to Faraday
• Add I2C data gathering code to Faraday for each sensor
• Add I2C data to telemetry packets
  • Likely going to need to make multiple telemetry packets to fit it all so a good restructuring of telemetry is a good idea

Rpi Based I2C

• Create scripts to gather I2C sensor data
• Create scripts to EITHER
  • Send I2C data to faraday and have faraday create packets
  • Directly create packets in RPi and only have Faraday transmit them

I think that we might want to consider if moving to a much more scale-able telemetry creation implementation is a good idea and base it heavily on RPi? Maybe leave the ability for Faraday's base telemetry but add/modify to easily scale into N amount of data from a RPi through proxy that is sent over RF.

Maybe Faraday abstracts a "telemetry" packet and type like it does now but add the functionality to sends new packets from a remote computer source (RPi).

Currently: Telem Packet #1 = System data (i.e. frequency) Telem Packet #2 = Debug information Telem Packet #3 = Faraday Sensor Telemetry (i.e ADC/GPS/etc...)

Maybe the easiest to do is just add additional packet types (i.e. #4) and let them come from the RPi itself and Faraday simply wraps it and sends is as a telemetry packet?

If we do this do we want to both with I2C on Faraday right now and just have RPi do it? This leaves any basic GPIO/ADC's for Faraday but any hardcore sensors go to I2C on RPi.

This may spur a small side project on Faraday Software for a "Sensors/Telemetry Generating Program" that runs with Proxy to gather and create generic telemetry...

[kb1lqc]

I'll respond in the morning @kb1lqd but it occured to me. What about using I2C SRAM instead of switching between SPI and I2C? This seems to solve the crossing of the stream so-to-speak.

[kb1lqc]

You should at least give I2C a shot on Faraday. It makes sense to not have to use the RPI to do this. In the future we may want to delegate much to the RPI I agree.

Make sure to consider the options that would make this quicker. What do you think about using an I2C to SPI converter and keeping everything SPI to the CC430 and all external I2C goes through the converter? the CP2120 is an example and here is a dev board. Building a simple converter board or finding a low-cost alternative could help us immensely. Let's not brute force this is we don't have to.

Will a SPI to I2C converter help a lot?

[kb1lqc]

Sensors in transit @kb1lqd:

• https://www.adafruit.com/product/1733
• https://www.adafruit.com/product/1777
• https://www.adafruit.com/product/165
• https://www.adafruit.com/product/1782
• https://www.adafruit.com/product/1293
• https://www.adafruit.com/product/1120
• http://www.shop.inspeed.com/E-Vane-II-Electronic-Wind-Direction-Sensor-EV2.htm;jsessionid=28DB9A7BB5577BB5D85A400A4C2D0167.p3plqscsfapp006

[kb1lqd]

Sensors received. Closing to allow integration and scalings to be tracked with more granularity after this initial selection and system design.