Jump to content
43oh

chicken

Members
  • Content Count

    908
  • Joined

  • Last visited

  • Days Won

    85

Reputation Activity

  1. Like
    chicken reacted to PTB in Stellaris Launchpad - Camera Flash Timer and Measurement Tool   
    Camera Flash Timer and Measurement Tool
     
     
     
    This project is an amalgamation of many other ideas and projects by other brilliant folks plus my own twist on things.
    Hopefully I have given credit to all those whose work I have expanded upon and incorporated.
    Apart from libraries, I have written the majority of the code from scratch implementing what I have learnt from this and other forums.
    Still quite a few bugs and it is probably 80 - 90% complete.
    I did get some perspex laser cut for it, but I didnt have the right software for it and borked the file conversion and received cute little minature versions.
    Will have another shot at that in the near future.
     
    Particular mention goes to the following folks for their posts and/or help.
    Maurice Ribble, Creator of the Camera Axe and Original Multiflash.
    @@RobG , Colour LCD with Touch https://www.tindie.com/products/RobG/color-lcd-boosterpack-touch/ I would be lost without this boosterpack and assistance.
    @@jkabat , http://forum.stellarisiti.com/topic/684-stellaris-fast-analog-reads/ John's Assistance with the Fast Analog reads required was awesome. Thanks!
    @@Rei Vilo, For help on many matters.
    @@calinp, For the porting of PetitFatfs.
    @@bluehash, For the SD card boosterpack. I have pretty much directly copied this circuit into my board.
     
    Thanks guys
     
    Main Components.
     
    RobG's Touchscreen Booster Pack.
    Stellaris Launchpad
    SD Card Socket
    I2C EEPROM
    Flash Sensor
    OptoIsoloators for Flashes
    Indicator LEDs
    Phototransistor
     
    Useage
     
    Takes the original flash signal and triggers up to 8 additonal flashes. The flashes can be either fired instantly or via delayed timings of which there are multiple modes.
     
    - Instant
    - Constant
    - Varies
    - Factor Increasing
    - Factor Decreasing
    - Synchronize
     

     

     

     

     

     
     
    It can also measure T0.1 and T0.5 camera flash durations via another menu.
     

     

     
    For ages I couldn't figure out what the spike was prior to many of the flash measurements. I am thinking it is a prepulse to the main flash which helps ionize the flash prior to main burst.
    If that's what it is, I am pretty stoked I can see it. Just need to modify my calcs routine to ignore it.
     
    http://en.wikipedia.org/wiki/Flashtube
     
    The purpose of measuring the flash lags and durations is an attempt to align flashes with different characteristics so that they are as closely synced as possible which removes ghosting of images.
     
    Jkabats help with fast analog routine has been key to achieving the 1Msps sampling rate.
     
    As each flash is profiled, the full curve data is stored in an I2C EEPROM along with summary details. This is then extracted by the Synchronize routine to set the delays for each flash.
    I have 7 different modes for aligning the flashes timewise. The results don’t differ too much depending on choice of method.
     
    1. Peak (default)
    2. T0.1 Midpoint
    3. T0.1 Centroid of area under curve
    4. T0.5 Midpoint
    5. T0.5 Centroid of area under curve
    6. Full Curve Midpoint
    7. Full Curve Centroid of area under curve
     
    The faster flashes are held back, and they all cross the finish line at the same time.
    The whole flash array inherits the lag of the slowest flash.
     
    All the data from the I2C chip can be written to an SD Card for further analysis on a PC. Here is the data ported to excel.
     

     
    Code
     
    The code is still underway but most things are working.
    This is version 0.26
     
    PTB_Flash_Measurement_Tool.zip
    (The main file is PTB_Iridium.INO . Will need to create folder structure to suit)
     
    Schematic
     
    This is the current schematic but will be updated in the near future to fix some problems.
    Multiflash 3.sch.pdf
     
    Stellaris Launchpad Mods
     
    Remove Resistors R2, R9, R10, R11, R12.
     
    Bugs and Issues
     
    Slowly working through things.
     
    1. Flash Port 3 isn't firing for some reason. I think it used to. I wonder if it is related to issue #2 below.
    2. I ran into strife with my indicator leds. They are Dual Colour red/blue and then I got a better understanding of forward voltage.
    The blue is very close to the operating voltage of 3.3v. I have done arduino thing before this and it was all 5v, so it caught me. (again)
    I am waiting on some lower resistance arrays, but I think this may create other problems to do with how much current the Stellaris can sink.
    http://e2e.ti.com/support/microcontrollers/stellaris_arm/f/471/t/45816.aspx
    Sooooo... I plan to redo the schematic in the near future implementing a darlington array to drive the optos and indicator leds.
    Gotta think that through. It will be my third board revision. Can't keep doing that forever.
    3. I seem to be only able to get it to run with Energia 0009 at the moment. Later versions don't seem to work with touch screen. Deffo my Software issue.
    4. I2C EEPROM Speeds are very slow. There is a lot of data I am writing in there, but I think some better coding on my part will help a lot.
    Luckily that only really affects 2 operations. The rest is zippy enough.
    5. Haven't written code for reading back from SD card into I2C EEPROM Chip.
    6. I seem to have some kind of problem with I2C addressing. I think its an Energia Wire library thing which may have been fixed in later versions.
    I had a 24lc512 but I wanted more space so I dropped in a 24lc1025 which I then found is like 2 different addresses.
    Couldn't write to one bank without writing to the other, so it defeated the purpose. I want more space to save longer curves from more powerful flashes.
    It is currently good enough to deal with common flashes at full power.
    7. I too have the problem of scanning the I2C bus and getting an address found at every address. The I2C Eeprom works as required though.
     
    More as I think of them.....
     
     
    Cheers
     
    PTB
  2. Like
    chicken got a reaction from energia in I2C in Tiva C   
    I didn't verify, but on Tiva int might be 32bit instead of 16.
     
    If that's the case, you should use int16_t in the 2nd half of the declaration of xyz_union.
     

    typedef union xyz_union { struct { uint8_t x_lsb; uint8_t x_msb; uint8_t y_lsb; uint8_t y_msb; uint8_t z_lsb; uint8_t z_msb; } reg; struct { int x; int y; int z; } value; };
  3. Like
    chicken got a reaction from energia in Somebody help me please   
    It looks like the conflict is not in the headers, but in a source file called CCS_e.cpp that seems to be part of your project. My guess is that the files you copied over from another project already contain their own interrupt handlers, including one for the watchdog timer.
     
    You won't succeed in combining a CCS project with an Energia project if you don't understand the code that you want to reuse. Either you take apart the Energia library and reimplement or wrap the code that relies on the Energia framework. Or you take the relevant part of the CCS project and convert it into an Energia library. In either case, there's no shortcut around understanding at least the structure of the code you try to reuse.
  4. Like
    chicken got a reaction from RobG in Products using MSP430   
    3 MSP430's controlling LEDs and buttons in the new Mac Pro?
    http://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778#s56753
     
    From the package (VQFN40?) it could be MSP430F23x0. Though the only trace of a MSP430F2380 can be found on a Chinese website (http://www.bdtic.com/TI/MSP430/MSP430F2380.html)

  5. Like
    chicken got a reaction from bluehash in [POTM] dAISy - A Simple AIS Receiver   
    @@simpleavr No, the received data is very precise. But unfortunately I forgot to update the default low-res vector map of OpenCPN on my notebook before heading out. There are free high resolution navigational maps that one has to download and install seperately.
     
    Below how the background would have looked like when adding local maps. I'll do another screenshot when I head out next time.
     
    --edit: forgot attachment

  6. Like
    chicken got a reaction from yyrkoon in [POTM] dAISy - A Simple AIS Receiver   
    Overview
    dAISy (do AIS yourself) is a very simple AIS receiver that I developed from scratch. It is built around the Silicon Labs EZRadioPRO Si4362 receiver, using a Texas Instruments MSP430G2553 MCU for processing and the MSP-EXP430G2 v1.5 LaunchPad as development platform.

    The complete project source code and schematics are available on GitHub: https://github.com/astuder/dAISy

    Update 5/18/2015: A finished, self-contained AIS receiver based on this project is now available for purchase in my web store.
     
    AIS, short for Automatic Identification System, is a standard for tracking ships. Ships advertise their position, course and other information with short transmissions on specific frequencies (161.975 MHz and 162.025 MHz). More on Wikipedia.
     
    An AIS receiver, like dAISy, receives and decodes AIS transmissions. It then re-packages the raw data into NMEA sentences (specifically formatted ASCII strings). Finally, using a serial connection, these strings are forwarded to more capable equipment for further processing.
     

     
    If you're the lucky owner of a tricked out boat, you could connect dAISy to your navigation computer. For land lobbers like me, a more common use case is to run naval mapping software that supports AIS data input on a PC. In the screenshot below I've connected dAISy to OpenCPN (link), an open source chart plotter and navigation software.
     

     
    On the top right you can see my setup war-driving at the Seattle waterfront as my lab is too far from the coast to receive anything. The LaunchPad sits on the dashboard with a white USB cable connecting to the notebook computer in the foreground.
     
    dAISy's data is fed into OpenCPN, bottom right shows a log of the serial data received. OpenCPN maintains a database of all the collected data (lower left) and visualizes nearby ships on a map (top center), including past and projected course. Hovering the mouse over a ship will display its name (text on yellow ground) and clicking it will reveal more detail (top left).
     
    Hardware
    I wanted to build my own, non-SDR, AIS receiver for a long time. There are a few projects floating around the internet (e.g. here) which refer back to an article by Peter Baston, published 2008 in Circuit Cellar magazine (copy available here gone.. google for Peter Baston Circuit Cellar to find other copies). Unfortunately, the CMX family of modem ICs by CMS Microcircuits (link) used in these projects are relatively expensive ($15+) and hard to find for hobbyists. In addition you'd need a radio to do tune into and down-convert from the ~162 MHz carrier frequency.
     
    So I was quite excited when earlier this year a parametric search on Mouser brought up a new IC  that covered the required range (162 MHz) and modulation (GMSK). And best of all, available in single quantities for $3.56 $2.27 $2.22! (link)
     
    The Silicon Labs EzRadioPRO Si4362 (link) is a single chip receiver that covers frequencies from 142 to 1050 MHz and supports various modulations, including GMSK. It comes in a tiny 20-pin QFN package and the only external parts required are a 30 MHz crystal, an antenna with a few capacitors and inductors for impedance matching, and finally some decoupling caps and pull-down resistors.
     
    Time to whip up a breakout board. I used the opportunity to give KiCad a try and quite like it.
     
    Here's the schematic:

     
    And the layout:

     
    I used OSHPark to make the PCBs. At a smidgen over one square inch it cost  $5.15 for 3 copies:

    http://oshpark.com/shared_projects/QUWi71r4
     
    Note that the layout still has three issues that I already fixed in the schematic:
    GPIO0 and GPIO1 were flipped SDO required a pull-down resistor as the radio leaves it floating when not actively sending, which confused the hell out of me while trying to figure out the communication protocol. Lastly, the holes for the headers turned out to be slightly too small to comfortably fit the cheap breakout headers I had at hand. Edit: Here's Rev B where I fixed these issues: http://oshpark.com/shared_projects/WI6u3Qmk
     
    Which brings us to the BOM:
    Silicon Labs Si4362 (U1) 30 MHz crystal (X1) Si4362 datasheet specifies <11 pF load capacitance, but a crystal specified for 12pF load capacitance seems to work fine too Antenna/LNA matching network, calculated based on SiLabs AN643 (link, approx. values, +/- 5% shouldn't matter too much): 75 ohm (dipole): 10 pF (CR1), 5 pF (CR2), 280 nH (LR1), 200 nH (LR2) 50 ohm: 12 pF (CR1), 6 pF (CR2), 240 nH (LR1), 160 nH (LR2) Decoupling caps: 100 pF, 100 nF, 1uF (C1, C2, C3) Pull-down resistors 100 k (R1, R2) First thing I noticed when I received the parts: The 20-pin QFN at 4x4 millimeters is tiny!

     
    I mounted it by first tinning the pads with a small quantity of solder. I then added flux and placed the chip on the pad. I then used a hot air station to carefully reflow the solder. Worked the first time around.

    After using jumper wires to figure out how to talk to the chip, I mounted the breakout board on a makeshift BoosterPack using perfboard, double-sided tape and wire (see picture at the top of the post).



    Here's how I ended up connecting the breakout board to the LaunchPad / MSP430G2553:
    SEL -> P1.4 (SPI chip select) SCLK -> P1.5 (SPI CLK) SDO -> P1.6 (SPI MISO) SDI -> P1.7 (SPI MOSI) GPIO0 -> P2.0 (I/O unused) GPIO1 -> P2.1 (I/O clear-to-send) GPIO2 -> P2.2 (I/O RX clock) GPIO3 -> P2.3 (I/O RX data) SDN -> P2.4 (shutdown / reset) IRQ -> P2.5 (I/O channel-clear) Software
    The software of dAISy consists of three major blocks:
    Radio configuration and control over SPI Packet handler, including a basic FIFO for received messages NMEA encoding and transmission to the PC over UART For UART (TX only) and SPI (TX/RX) I use the MSP430G2553's USCI A0 and B0 respectively. In both cases I don't use interrupts which simplifies things considerably.
     
    Upon reset the following steps happen:
    Initialize MSP430 peripherals Initialize packet handler, which will also reset FIFO Initialize and configure of radio, which will also setup SPI Start packet handler, which will also put the radio into receive mode And in the main loop:
    If debug messages are enabled, poll packet handler for status and errors and report them over UART Check FIFO for new packets If there is a new packet, invoke NMEA processing (which sends the message over serial to the PC) and remove packet from FIFO Below follows a more detailed discussion of the radio integration and the implementation of the packet handler.
     
    Radio
    The communication with the radio is vanilla SPI using 4 wires: MOSI (SDI), MISO (SDO), CLK (SCLK) and CS (SEL). I used the MSP430's USCI B0 to implement SPI and a separate pin to control CS.
     
    The only tricky thing to figure out was, that the Si4362 keeps the MISO line floating unless it actively transmits data. This is unfortunate as the master is supposed to poll for a specific response (FF) to detect when the radio is ready to receive more commands. This is easily fixed by adding a weak pull down resistor to SDO. I did this on the board, but it probably also works with using MSP430's internal pull-down.
     
    Additional lines I used to control the radio are:
    SDN to reset the radio CTS, which by default is mapped to the radio's GPIO1, indicating that the radio is ready for the next command While taking up an extra pin, CTS turned out to be much more convenient than the SPI response code to properly time communication flow with the radio. In dAISy, I wait for CTS to go high after each command to ensure the radio completed its task.
     
    The communication protocol is quite extensive but well documented:
    EZRadioPRO API Documentation describes the complete API and all registers AN633 Programming Guide for EZRadioPro Si4x6x Devices describes how to use the API in common scenarios Both are available on the Si4362 product page (link), under Documentation > Application Notes and are still updated quite frequently.
     
    The radio is set up by dumping a large configuration sequence into it. This includes configuration of radio frequency, modulation, GPIO pins and more. This information is stored in radio_config.h, which has to be generated with a tool called WDS (Wireless Development Suite). WDS is available in the Tools section on the Si4362 product site.
     

     
    Above are the settings I used for dAISy. WDS will use this information to configure various amplifiers, filters, clocks and decoding algorithms inside the chip. As Si4362 supports GMSK encoding only indirectly (see this thread), I'm certain there's more optimization potential by tweaking registers, but that's currently way beyond my knowledge of RF theory.
     
    While the Si4362 comes with its own packet handler, it unfortunately does not support NRZI encoding (Wikipedia). So I set up the radio to expose the 9600 baud clock and received data on separate pins and implemented my own packet handler.
     
    Packet Handler
    The packet handler (inspired by Peter Baston's implementation) is implemented as a state machine that is invoked on each rising edge of pin P2.2 which receives the data clock.
     

    There are 5 main states:
    Off, no processing of incoming data Reset, start from anew, either on start up or after successful/failed processing of a packet Wait for Sync, waiting for a training sequence to arrive (010101..) and start flag (01111110), implemented with its own state machine   Reset, start new preamble 0, last bit was a zero 1, last bit was a one flag, training sequence complete, now process start flag Prefetch, ingest the next 8 message bits to ease further processing Receive Packet, process bits until the end flag (01111110) is found or an error situation occurs Independent of state, the interrupt routine continually decodes NRZI into actual bit sequence.
     
    In the "Receive Packet" state there's continuous calculation of the packet CRC and some bit-de-stuffing. When the end flag is found and the CRC is correct, the received message is committed into the FIFO. If an error is encountered, the bytes already written to the FIFO are discarded. In both cases, the state machine starts anew by transitioning into RESET.
    This reads like a lot of code for an interrupt handler. However with the MCU running at 16MHz even the most complex state only uses a fraction (<10%) of the available time.
     
    Future Improvements
    Lastly a list of things I'd like to improve with the next version of dAISy.
     
    Software:
    Receiving on both AIS channels through channel-hopping done 1/5/2014 Tweak radio settings for better sensitivity and lower error rate LED(s) for indicating reception of valid/corrupt packets Hardware:
    Proper antenna connector Layout PCB as BoosterPack and/or USB dongle Receiving on both AIS channels at once with two radio ICs -- edit 12/25: replaced original post with high-level project description, more detailed documentation of implementation to come
    -- edit 12/28: added documentation for hardware (here and on Github), fixed some typos
    -- edit 12/31: added documentation for software and list of future improvements
    -- edit 01/05: implemented channel hopping (change to state machine)
    -- edit 01/15: changed state machine to reflect recent changes (see post further down for details), added link to shared project on OSHPark
    -- edit 01/25: major rework of sync detection state machine

  7. Like
    chicken got a reaction from markf in [POTM] dAISy - A Simple AIS Receiver   
    Finished up project documentation by adding description of software implementation and a list of future improvements.
     
    As I've no inkling about RF, I'm open for any input on how to improve sensitivity and lower error rate.
     
    And to an earlier question by @@simpleavr, below a recent annotated screen capture with more detailed maps and some action. I was located at the red X.

     
  8. Like
    chicken reacted to jrychter in I2C master using the USI module: a tiny library   
    I've written a tiny library that implements I2C master functionality on MSP430 devices that only have the USI module (for example, MSP430G2412 or MSP430G2452). It's small, simple, works well for me, and might help others in their projects.
     
    Blog post at http://jan.rychter.com/enblog/msp430-i2c-usi-library-released
     
    Github repo at https://github.com/jwr/msp430_usi_i2c
     
    Have fun!
     
     
  9. Like
    chicken got a reaction from tushki7 in Suggest Online seller - 160 segment lcd   
    I would search on Ebay for:
    [meter brand and/or model] replacement lcd [meter brand and/or model] replacement display
  10. Like
    chicken got a reaction from tripwire in [POTM] dAISy - A Simple AIS Receiver   
    Finished up project documentation by adding description of software implementation and a list of future improvements.
     
    As I've no inkling about RF, I'm open for any input on how to improve sensitivity and lower error rate.
     
    And to an earlier question by @@simpleavr, below a recent annotated screen capture with more detailed maps and some action. I was located at the red X.

     
  11. Like
    chicken got a reaction from JonnyBoats in [POTM] dAISy - A Simple AIS Receiver   
    Overview
    dAISy (do AIS yourself) is a very simple AIS receiver that I developed from scratch. It is built around the Silicon Labs EZRadioPRO Si4362 receiver, using a Texas Instruments MSP430G2553 MCU for processing and the MSP-EXP430G2 v1.5 LaunchPad as development platform.

    The complete project source code and schematics are available on GitHub: https://github.com/astuder/dAISy

    Update 5/18/2015: A finished, self-contained AIS receiver based on this project is now available for purchase in my web store.
     
    AIS, short for Automatic Identification System, is a standard for tracking ships. Ships advertise their position, course and other information with short transmissions on specific frequencies (161.975 MHz and 162.025 MHz). More on Wikipedia.
     
    An AIS receiver, like dAISy, receives and decodes AIS transmissions. It then re-packages the raw data into NMEA sentences (specifically formatted ASCII strings). Finally, using a serial connection, these strings are forwarded to more capable equipment for further processing.
     

     
    If you're the lucky owner of a tricked out boat, you could connect dAISy to your navigation computer. For land lobbers like me, a more common use case is to run naval mapping software that supports AIS data input on a PC. In the screenshot below I've connected dAISy to OpenCPN (link), an open source chart plotter and navigation software.
     

     
    On the top right you can see my setup war-driving at the Seattle waterfront as my lab is too far from the coast to receive anything. The LaunchPad sits on the dashboard with a white USB cable connecting to the notebook computer in the foreground.
     
    dAISy's data is fed into OpenCPN, bottom right shows a log of the serial data received. OpenCPN maintains a database of all the collected data (lower left) and visualizes nearby ships on a map (top center), including past and projected course. Hovering the mouse over a ship will display its name (text on yellow ground) and clicking it will reveal more detail (top left).
     
    Hardware
    I wanted to build my own, non-SDR, AIS receiver for a long time. There are a few projects floating around the internet (e.g. here) which refer back to an article by Peter Baston, published 2008 in Circuit Cellar magazine (copy available here gone.. google for Peter Baston Circuit Cellar to find other copies). Unfortunately, the CMX family of modem ICs by CMS Microcircuits (link) used in these projects are relatively expensive ($15+) and hard to find for hobbyists. In addition you'd need a radio to do tune into and down-convert from the ~162 MHz carrier frequency.
     
    So I was quite excited when earlier this year a parametric search on Mouser brought up a new IC  that covered the required range (162 MHz) and modulation (GMSK). And best of all, available in single quantities for $3.56 $2.27 $2.22! (link)
     
    The Silicon Labs EzRadioPRO Si4362 (link) is a single chip receiver that covers frequencies from 142 to 1050 MHz and supports various modulations, including GMSK. It comes in a tiny 20-pin QFN package and the only external parts required are a 30 MHz crystal, an antenna with a few capacitors and inductors for impedance matching, and finally some decoupling caps and pull-down resistors.
     
    Time to whip up a breakout board. I used the opportunity to give KiCad a try and quite like it.
     
    Here's the schematic:

     
    And the layout:

     
    I used OSHPark to make the PCBs. At a smidgen over one square inch it cost  $5.15 for 3 copies:

    http://oshpark.com/shared_projects/QUWi71r4
     
    Note that the layout still has three issues that I already fixed in the schematic:
    GPIO0 and GPIO1 were flipped SDO required a pull-down resistor as the radio leaves it floating when not actively sending, which confused the hell out of me while trying to figure out the communication protocol. Lastly, the holes for the headers turned out to be slightly too small to comfortably fit the cheap breakout headers I had at hand. Edit: Here's Rev B where I fixed these issues: http://oshpark.com/shared_projects/WI6u3Qmk
     
    Which brings us to the BOM:
    Silicon Labs Si4362 (U1) 30 MHz crystal (X1) Si4362 datasheet specifies <11 pF load capacitance, but a crystal specified for 12pF load capacitance seems to work fine too Antenna/LNA matching network, calculated based on SiLabs AN643 (link, approx. values, +/- 5% shouldn't matter too much): 75 ohm (dipole): 10 pF (CR1), 5 pF (CR2), 280 nH (LR1), 200 nH (LR2) 50 ohm: 12 pF (CR1), 6 pF (CR2), 240 nH (LR1), 160 nH (LR2) Decoupling caps: 100 pF, 100 nF, 1uF (C1, C2, C3) Pull-down resistors 100 k (R1, R2) First thing I noticed when I received the parts: The 20-pin QFN at 4x4 millimeters is tiny!

     
    I mounted it by first tinning the pads with a small quantity of solder. I then added flux and placed the chip on the pad. I then used a hot air station to carefully reflow the solder. Worked the first time around.

    After using jumper wires to figure out how to talk to the chip, I mounted the breakout board on a makeshift BoosterPack using perfboard, double-sided tape and wire (see picture at the top of the post).



    Here's how I ended up connecting the breakout board to the LaunchPad / MSP430G2553:
    SEL -> P1.4 (SPI chip select) SCLK -> P1.5 (SPI CLK) SDO -> P1.6 (SPI MISO) SDI -> P1.7 (SPI MOSI) GPIO0 -> P2.0 (I/O unused) GPIO1 -> P2.1 (I/O clear-to-send) GPIO2 -> P2.2 (I/O RX clock) GPIO3 -> P2.3 (I/O RX data) SDN -> P2.4 (shutdown / reset) IRQ -> P2.5 (I/O channel-clear) Software
    The software of dAISy consists of three major blocks:
    Radio configuration and control over SPI Packet handler, including a basic FIFO for received messages NMEA encoding and transmission to the PC over UART For UART (TX only) and SPI (TX/RX) I use the MSP430G2553's USCI A0 and B0 respectively. In both cases I don't use interrupts which simplifies things considerably.
     
    Upon reset the following steps happen:
    Initialize MSP430 peripherals Initialize packet handler, which will also reset FIFO Initialize and configure of radio, which will also setup SPI Start packet handler, which will also put the radio into receive mode And in the main loop:
    If debug messages are enabled, poll packet handler for status and errors and report them over UART Check FIFO for new packets If there is a new packet, invoke NMEA processing (which sends the message over serial to the PC) and remove packet from FIFO Below follows a more detailed discussion of the radio integration and the implementation of the packet handler.
     
    Radio
    The communication with the radio is vanilla SPI using 4 wires: MOSI (SDI), MISO (SDO), CLK (SCLK) and CS (SEL). I used the MSP430's USCI B0 to implement SPI and a separate pin to control CS.
     
    The only tricky thing to figure out was, that the Si4362 keeps the MISO line floating unless it actively transmits data. This is unfortunate as the master is supposed to poll for a specific response (FF) to detect when the radio is ready to receive more commands. This is easily fixed by adding a weak pull down resistor to SDO. I did this on the board, but it probably also works with using MSP430's internal pull-down.
     
    Additional lines I used to control the radio are:
    SDN to reset the radio CTS, which by default is mapped to the radio's GPIO1, indicating that the radio is ready for the next command While taking up an extra pin, CTS turned out to be much more convenient than the SPI response code to properly time communication flow with the radio. In dAISy, I wait for CTS to go high after each command to ensure the radio completed its task.
     
    The communication protocol is quite extensive but well documented:
    EZRadioPRO API Documentation describes the complete API and all registers AN633 Programming Guide for EZRadioPro Si4x6x Devices describes how to use the API in common scenarios Both are available on the Si4362 product page (link), under Documentation > Application Notes and are still updated quite frequently.
     
    The radio is set up by dumping a large configuration sequence into it. This includes configuration of radio frequency, modulation, GPIO pins and more. This information is stored in radio_config.h, which has to be generated with a tool called WDS (Wireless Development Suite). WDS is available in the Tools section on the Si4362 product site.
     

     
    Above are the settings I used for dAISy. WDS will use this information to configure various amplifiers, filters, clocks and decoding algorithms inside the chip. As Si4362 supports GMSK encoding only indirectly (see this thread), I'm certain there's more optimization potential by tweaking registers, but that's currently way beyond my knowledge of RF theory.
     
    While the Si4362 comes with its own packet handler, it unfortunately does not support NRZI encoding (Wikipedia). So I set up the radio to expose the 9600 baud clock and received data on separate pins and implemented my own packet handler.
     
    Packet Handler
    The packet handler (inspired by Peter Baston's implementation) is implemented as a state machine that is invoked on each rising edge of pin P2.2 which receives the data clock.
     

    There are 5 main states:
    Off, no processing of incoming data Reset, start from anew, either on start up or after successful/failed processing of a packet Wait for Sync, waiting for a training sequence to arrive (010101..) and start flag (01111110), implemented with its own state machine   Reset, start new preamble 0, last bit was a zero 1, last bit was a one flag, training sequence complete, now process start flag Prefetch, ingest the next 8 message bits to ease further processing Receive Packet, process bits until the end flag (01111110) is found or an error situation occurs Independent of state, the interrupt routine continually decodes NRZI into actual bit sequence.
     
    In the "Receive Packet" state there's continuous calculation of the packet CRC and some bit-de-stuffing. When the end flag is found and the CRC is correct, the received message is committed into the FIFO. If an error is encountered, the bytes already written to the FIFO are discarded. In both cases, the state machine starts anew by transitioning into RESET.
    This reads like a lot of code for an interrupt handler. However with the MCU running at 16MHz even the most complex state only uses a fraction (<10%) of the available time.
     
    Future Improvements
    Lastly a list of things I'd like to improve with the next version of dAISy.
     
    Software:
    Receiving on both AIS channels through channel-hopping done 1/5/2014 Tweak radio settings for better sensitivity and lower error rate LED(s) for indicating reception of valid/corrupt packets Hardware:
    Proper antenna connector Layout PCB as BoosterPack and/or USB dongle Receiving on both AIS channels at once with two radio ICs -- edit 12/25: replaced original post with high-level project description, more detailed documentation of implementation to come
    -- edit 12/28: added documentation for hardware (here and on Github), fixed some typos
    -- edit 12/31: added documentation for software and list of future improvements
    -- edit 01/05: implemented channel hopping (change to state machine)
    -- edit 01/15: changed state machine to reflect recent changes (see post further down for details), added link to shared project on OSHPark
    -- edit 01/25: major rework of sync detection state machine

  12. Like
    chicken got a reaction from tripwire in [ ENDED ] Nov 2013 - Jan 2014 - 43oh Project of the Month Contest   
    Officially entering my project into the POTM contest
     
    dAISy is a piece of kit that can receive position data from ships.
     
      Detailed project description:
    http://forum.43oh.com/topic/4833-potm-daisy-a-simple-ais-receiver/
     
    Source code and schematics:
    https://github.com/astuder/dAISy
  13. Like
    chicken got a reaction from tripwire in Products using MSP430   
    Looks like Mikey got an update
    http://08milluz.wordpress.com/2013/11/11/glow-with-the-show-ears-teardown/
    .. or maybe it's an older version, definitely a different revision (GlowEars v1.5)
     
    Still an MSP430G2553 though.
  14. Like
    chicken got a reaction from tripwire in Products using MSP430   
    MSP430F5259 found in the new Motorola Moto X
    http://www.ifixit.com/Teardown/Motorola+Moto+X+Teardown/16867/2 (step 15)
     
    There's also a beefy TI C5000 DSP involved.
  15. Like
    chicken got a reaction from tripwire in [ADMIN]MSP430G2553   
    Copy&paste both into notepad and save the file. Done!
     
    Sorry for being a cynic, but this must be your 10th post in two days in this inappropriate style.
     
    Please:
    1) use the topic to describe the content of your post, e.g. "how can I add uart to captouch example".
     
    2) don't simply throw source code at us and expect someone spending their time to do your work. Assuming you actually tried to solve the problem yourself, describe what you did and where you are stuck.
     
    3) If you're completely lost and don't know what question to ask, you should consider to start experimenting with the individual pieces and try to understand them first - divide and conquer.
     
    You will find a lot of people here that quickly answer specific questions about specific topics.
  16. Like
    chicken got a reaction from bluehash in [ADMIN]MSP430G2553   
    Copy&paste both into notepad and save the file. Done!
     
    Sorry for being a cynic, but this must be your 10th post in two days in this inappropriate style.
     
    Please:
    1) use the topic to describe the content of your post, e.g. "how can I add uart to captouch example".
     
    2) don't simply throw source code at us and expect someone spending their time to do your work. Assuming you actually tried to solve the problem yourself, describe what you did and where you are stuck.
     
    3) If you're completely lost and don't know what question to ask, you should consider to start experimenting with the individual pieces and try to understand them first - divide and conquer.
     
    You will find a lot of people here that quickly answer specific questions about specific topics.
  17. Like
    chicken got a reaction from roadrunner84 in [ADMIN]MSP430G2553   
    Copy&paste both into notepad and save the file. Done!
     
    Sorry for being a cynic, but this must be your 10th post in two days in this inappropriate style.
     
    Please:
    1) use the topic to describe the content of your post, e.g. "how can I add uart to captouch example".
     
    2) don't simply throw source code at us and expect someone spending their time to do your work. Assuming you actually tried to solve the problem yourself, describe what you did and where you are stuck.
     
    3) If you're completely lost and don't know what question to ask, you should consider to start experimenting with the individual pieces and try to understand them first - divide and conquer.
     
    You will find a lot of people here that quickly answer specific questions about specific topics.
  18. Like
    chicken got a reaction from supamas in [Energia Library] Bosch BMP085 Template Library   
    Ok, I get the same error with Energia E0011.
     
    For what it's worth, even the Blink sketch throws a similar error. E0010 works just fine.
     
    here the last line of the detailed compile output and the error:
     

    C:\Other Programs\energia-0101E0011\hardware\tools\msp430\bin\msp430-gcc -Os -Wl,-gc-sections,-u,main -mmcu=msp430f5529 -o C:\Users\Adrian2\AppData\Local\Temp\build9069550804598847055.tmp\Blink.cpp.elf C:\Users\Adrian2\AppData\Local\Temp\build9069550804598847055.tmp\Blink.cpp.o C:\Users\Adrian2\AppData\Local\Temp\build9069550804598847055.tmp\core.a -LC:\Users\Adrian2\AppData\Local\Temp\build9069550804598847055.tmp -lm c:/other programs/energia-0101e0011/hardware/tools/msp430/bin/../lib/gcc/msp430/4.6.3/../../../../msp430/bin/ld.exe: cannot open linker script file memory.x: No such file or directory collect2: ld returned 1 exit status And for what it's worth, here the same command that works in E0010:
    C:\Other Programs\energia-0101E0010\hardware\tools\msp430\bin\msp430-gcc -Os -Wl,-gc-sections,-u,main -mmcu=msp430f5529 -o C:\Users\Adrian2\AppData\Local\Temp\build1899634374725368843.tmp\Blink.cpp.elf C:\Users\Adrian2\AppData\Local\Temp\build1899634374725368843.tmp\Blink.cpp.o C:\Users\Adrian2\AppData\Local\Temp\build1899634374725368843.tmp\core.a -LC:\Users\Adrian2\AppData\Local\Temp\build1899634374725368843.tmp -lm Maybe someone familiar with the Energia build system can spot the issue.
  19. Like
    chicken got a reaction from supamas in [Energia Library] Bosch BMP085 Template Library   
    You know what? The "no space in path" finally got me. Interestingly it works fine for Energia 0009 and 0010.
     
    Move Energia 0011 into a parent folder that has no spaces, and Blink as well as my example will compile.
  20. Like
    chicken got a reaction from simpleavr in [POTM] dAISy - A Simple AIS Receiver   
    Finished up project documentation by adding description of software implementation and a list of future improvements.
     
    As I've no inkling about RF, I'm open for any input on how to improve sensitivity and lower error rate.
     
    And to an earlier question by @@simpleavr, below a recent annotated screen capture with more detailed maps and some action. I was located at the red X.

     
  21. Like
    chicken got a reaction from bluehash in [POTM] dAISy - A Simple AIS Receiver   
    Finished up project documentation by adding description of software implementation and a list of future improvements.
     
    As I've no inkling about RF, I'm open for any input on how to improve sensitivity and lower error rate.
     
    And to an earlier question by @@simpleavr, below a recent annotated screen capture with more detailed maps and some action. I was located at the red X.

     
  22. Like
    chicken got a reaction from bluehash in Products using MSP430   
    3 MSP430's controlling LEDs and buttons in the new Mac Pro?
    http://www.ifixit.com/Teardown/Mac+Pro+Late+2013+Teardown/20778#s56753
     
    From the package (VQFN40?) it could be MSP430F23x0. Though the only trace of a MSP430F2380 can be found on a Chinese website (http://www.bdtic.com/TI/MSP430/MSP430F2380.html)

  23. Like
    chicken got a reaction from spirilis in [ ENDED ] Nov 2013 - Jan 2014 - 43oh Project of the Month Contest   
    Officially entering my project into the POTM contest
     
    dAISy is a piece of kit that can receive position data from ships.
     
      Detailed project description:
    http://forum.43oh.com/topic/4833-potm-daisy-a-simple-ais-receiver/
     
    Source code and schematics:
    https://github.com/astuder/dAISy
  24. Like
    chicken reacted to pjkim in SubiCount: an improved tally counter   
    My day job is a rheumatologist and immunology researcher. An important but stupid-boring part of research involves an accurate counting of cells. Whether you work in  immunology, cancer biology, sperm counting, etc, an accurate cell count is essential for meaningful and reproducible results. There are electronic Coulter counters but they are expensive and unless you are constantly counting cells, it doesn't make sense because of the constant adjusting and cleaning involved.
     
    When I was first shown how to count cells, I thought they were taking the new guy on a snipe hunt! You take a suspension of cells and put 10 microliters (ul) to a specially calibrated slide called a hemocytometer. It has a calibrated grid of lines and a precision ground spacing between the slide and coverslip so that the volume of fluid being examined is precisely known. You typically count the number of cells in a 1 x 1 x 0.1 mm (0.1 ul) volume. So for example if you count 100 cells, you have 100/0.1ul = 1 million cells/ml.
     
    See http://en.wikipedia.org/wiki/Hemocytometer for pictures and an explanation. If you want accurate and reproducible results, you need to do a good job. Once you learn few rules, it is easy but at the same time mind numbing and tedious.
     
    A friend of mine did research on subtizing (https://en.wikipedia.org/wiki/Subitizing). Whats that you say? If I flash up fingers for a fraction of a second, you don't count the individual fingers-- you instantly recognize the number. Most people can subitize up to ~5 or 6 items and as you can imagine, it is much faster than counting. I wanted to see if I could subitize to speed up counting. Enter the SubiCount.
     
    The hardware is rather simple so I routed the board manually, i.e. without a schematic. Two transistors, two resistors and a bypass cap. The first version of the firmware was not particularly power efficient-- it was constantly in LPM3 with a timer driven interrupt routine. About 100 times per second, it would run a button debounce routine, take care of sending pulses to the tally counter, and fall back into LPM3. Pulses to the tally counter need to be sent at a controlled rate otherwise pulses get lost. The MSP430 keeps track of how many need to be streamed to the tally counter.
     
    Problem was, it would do this 24/7 regardless of whether it was being used or not. Despite this, the two button cell batteries lasted three and a half months. For my project entry, I wanted to really leverage the low power aspect of the MSP430. I haven't had a chance to see what the new battery life is but I reckon it will likely be several years because it spends the bulk of its time in LPM4.
     
    Here is a video of SubiCount in action:
    https://www.youtube.com/watch?v=_fc95bzSDj4
     
    My implementation was to stay in LPM4. From LPM4, pressing any of the buttons will trigger a PORT1 interrupt which puts the 430 into LPM3 and turns off the PORT1 interrupt. In LPM3, a timer driven interrupt routine is called 100 times per second to debounce buttons and send pulses to the tally counter. When all the pulses are sent and no button presses are active or pending, the PORT1 interrupt is turned back on and goes into LPM4.
     
    Here is the code for main. It does nothing other than turning on global interrupts and going into LPM3.
    int main(void) { Grace_init(); // Activate Grace-generated configuration // >>>>> Fill-in user code here <<<<< _BIS_SR(LPM3_bits + GIE); // never should get here } The meat is in two interrupt routines: one for PORT1 and another for TimerA0. I used GRACE so the code is in the automatically generated InterruptVectors_init.c file. Comments have been edited out for brevity:
    #include <msp430.h> /* SubiCount by Peter Kim 2013. Creative Commons License: Attribution-NonCommercial-ShareAlike 4.0 International */ /* USER CODE START (section: InterruptVectors_init_c_prologue) */ /* User defined includes, defines, global variables and functions */ #define MAXDEBOUNCE 2 //threshold for debounce #define MAXRESET 300 // threshold for three button reset int processKey(unsigned int pinValue, unsigned int *pkeyInteg, unsigned int *plastValue); int i; unsigned int oneKeyInteg = 0; unsigned int twoKeyInteg = 0; unsigned int threeKeyInteg = 0; unsigned int resetInteg = 0; unsigned int oneKeyLastVal = 0; unsigned int twoKeyLastVal = 0; unsigned int threeKeyLastVal = 0; volatile unsigned int pulses; int processKey(unsigned int pinValue, unsigned int *pkeyInteg, unsigned int *plastValue) { /* Debounce routine adapted from http://www.kennethkuhn.com/electronics/debounce.c */ int posEdge = 0; if (pinValue) //pinValue inverted { if (*pkeyInteg > 0) (*pkeyInteg)--; } else if (*pkeyInteg < MAXDEBOUNCE) (*pkeyInteg)++; if (*pkeyInteg == 0) *plastValue = 0; else if (*pkeyInteg >= MAXDEBOUNCE && *plastValue == 0) { posEdge = 1; *plastValue = 1; *pkeyInteg = MAXDEBOUNCE; /* defensive code if integrator got corrupted */ } return(posEdge); } void InterruptVectors_graceInit(void) { } #pragma vector=PORT1_VECTOR __interrupt void PORT1_ISR_HOOK(void) { /* USER CODE START (section: PORT1_ISR_HOOK) */ P1IFG &= ~(BIT3+BIT2+BIT1); //clear interrupt flag P1IE &= ~(BIT3+BIT2+BIT1); //clear P1.3 interrupt enable __bic_SR_register_on_exit(OSCOFF); //put into LPM3 /* USER CODE END (section: PORT1_ISR_HOOK) */ } /* * ======== Timer_A2 Interrupt Service Routine ======== */ #pragma vector=TIMERA0_VECTOR __interrupt void TIMERA0_ISR_HOOK(void) { /* USER CODE START (section: TIMERA0_ISR_HOOK) */ static int count =0; // to keep track of times here int P1; P1 = P1IN; if ( processKey(P1 & BIT1, &oneKeyInteg, &oneKeyLastVal) ) pulses++; if ( processKey(P1 & BIT2, &twoKeyInteg, &twoKeyLastVal) ) { pulses += 2; } if ( processKey(P1 & BIT3, &threeKeyInteg, &threeKeyLastVal) ) { pulses += 3; } if ( (P1 & (BIT1|BIT2|BIT3)) == 0) { resetInteg++; if (resetInteg > MAXRESET) { resetInteg = 0; P1OUT |= BIT6; //turn on bit6, reset _delay_cycles(40000); P1OUT = BIT1|BIT2|BIT3; //need pull ups on pulses = 0; //reset pulses count after reset return; } } else if (resetInteg) resetInteg--; if (count++ >7) { count = 0; if (P1OUT & BIT0) //count pin high? { P1OUT &= ~BIT0; //then turn off pulses--; //and decrement pulses } else if (pulses) { P1OUT |= BIT0; //turn on count pin } } if (pulses == 0) // done with pulses? { if ( (P1IN & BIT1+BIT2+BIT3) == BIT1+BIT2+BIT3 ) //are all buttons not pressed? { if (oneKeyLastVal==0 && twoKeyLastVal==0 && threeKeyLastVal==0) { P1IFG &= ~(BIT3+BIT2+BIT1); //clear P1.3 int flag P1IE |= BIT3+BIT2+BIT1; //enable P1.3 interrupt __bis_SR_register_on_exit(LPM4_bits + GIE); //go into LPM4 } } } /* USER CODE END (section: TIMERA0_ISR_HOOK) */ }   Here is the hand routed board:

     
    And a hand drawn schematic:

  25. Like
    chicken got a reaction from GastonP in [POTM] dAISy - A Simple AIS Receiver   
    Overview
    dAISy (do AIS yourself) is a very simple AIS receiver that I developed from scratch. It is built around the Silicon Labs EZRadioPRO Si4362 receiver, using a Texas Instruments MSP430G2553 MCU for processing and the MSP-EXP430G2 v1.5 LaunchPad as development platform.

    The complete project source code and schematics are available on GitHub: https://github.com/astuder/dAISy

    Update 5/18/2015: A finished, self-contained AIS receiver based on this project is now available for purchase in my web store.
     
    AIS, short for Automatic Identification System, is a standard for tracking ships. Ships advertise their position, course and other information with short transmissions on specific frequencies (161.975 MHz and 162.025 MHz). More on Wikipedia.
     
    An AIS receiver, like dAISy, receives and decodes AIS transmissions. It then re-packages the raw data into NMEA sentences (specifically formatted ASCII strings). Finally, using a serial connection, these strings are forwarded to more capable equipment for further processing.
     

     
    If you're the lucky owner of a tricked out boat, you could connect dAISy to your navigation computer. For land lobbers like me, a more common use case is to run naval mapping software that supports AIS data input on a PC. In the screenshot below I've connected dAISy to OpenCPN (link), an open source chart plotter and navigation software.
     

     
    On the top right you can see my setup war-driving at the Seattle waterfront as my lab is too far from the coast to receive anything. The LaunchPad sits on the dashboard with a white USB cable connecting to the notebook computer in the foreground.
     
    dAISy's data is fed into OpenCPN, bottom right shows a log of the serial data received. OpenCPN maintains a database of all the collected data (lower left) and visualizes nearby ships on a map (top center), including past and projected course. Hovering the mouse over a ship will display its name (text on yellow ground) and clicking it will reveal more detail (top left).
     
    Hardware
    I wanted to build my own, non-SDR, AIS receiver for a long time. There are a few projects floating around the internet (e.g. here) which refer back to an article by Peter Baston, published 2008 in Circuit Cellar magazine (copy available here gone.. google for Peter Baston Circuit Cellar to find other copies). Unfortunately, the CMX family of modem ICs by CMS Microcircuits (link) used in these projects are relatively expensive ($15+) and hard to find for hobbyists. In addition you'd need a radio to do tune into and down-convert from the ~162 MHz carrier frequency.
     
    So I was quite excited when earlier this year a parametric search on Mouser brought up a new IC  that covered the required range (162 MHz) and modulation (GMSK). And best of all, available in single quantities for $3.56 $2.27 $2.22! (link)
     
    The Silicon Labs EzRadioPRO Si4362 (link) is a single chip receiver that covers frequencies from 142 to 1050 MHz and supports various modulations, including GMSK. It comes in a tiny 20-pin QFN package and the only external parts required are a 30 MHz crystal, an antenna with a few capacitors and inductors for impedance matching, and finally some decoupling caps and pull-down resistors.
     
    Time to whip up a breakout board. I used the opportunity to give KiCad a try and quite like it.
     
    Here's the schematic:

     
    And the layout:

     
    I used OSHPark to make the PCBs. At a smidgen over one square inch it cost  $5.15 for 3 copies:

    http://oshpark.com/shared_projects/QUWi71r4
     
    Note that the layout still has three issues that I already fixed in the schematic:
    GPIO0 and GPIO1 were flipped SDO required a pull-down resistor as the radio leaves it floating when not actively sending, which confused the hell out of me while trying to figure out the communication protocol. Lastly, the holes for the headers turned out to be slightly too small to comfortably fit the cheap breakout headers I had at hand. Edit: Here's Rev B where I fixed these issues: http://oshpark.com/shared_projects/WI6u3Qmk
     
    Which brings us to the BOM:
    Silicon Labs Si4362 (U1) 30 MHz crystal (X1) Si4362 datasheet specifies <11 pF load capacitance, but a crystal specified for 12pF load capacitance seems to work fine too Antenna/LNA matching network, calculated based on SiLabs AN643 (link, approx. values, +/- 5% shouldn't matter too much): 75 ohm (dipole): 10 pF (CR1), 5 pF (CR2), 280 nH (LR1), 200 nH (LR2) 50 ohm: 12 pF (CR1), 6 pF (CR2), 240 nH (LR1), 160 nH (LR2) Decoupling caps: 100 pF, 100 nF, 1uF (C1, C2, C3) Pull-down resistors 100 k (R1, R2) First thing I noticed when I received the parts: The 20-pin QFN at 4x4 millimeters is tiny!

     
    I mounted it by first tinning the pads with a small quantity of solder. I then added flux and placed the chip on the pad. I then used a hot air station to carefully reflow the solder. Worked the first time around.

    After using jumper wires to figure out how to talk to the chip, I mounted the breakout board on a makeshift BoosterPack using perfboard, double-sided tape and wire (see picture at the top of the post).



    Here's how I ended up connecting the breakout board to the LaunchPad / MSP430G2553:
    SEL -> P1.4 (SPI chip select) SCLK -> P1.5 (SPI CLK) SDO -> P1.6 (SPI MISO) SDI -> P1.7 (SPI MOSI) GPIO0 -> P2.0 (I/O unused) GPIO1 -> P2.1 (I/O clear-to-send) GPIO2 -> P2.2 (I/O RX clock) GPIO3 -> P2.3 (I/O RX data) SDN -> P2.4 (shutdown / reset) IRQ -> P2.5 (I/O channel-clear) Software
    The software of dAISy consists of three major blocks:
    Radio configuration and control over SPI Packet handler, including a basic FIFO for received messages NMEA encoding and transmission to the PC over UART For UART (TX only) and SPI (TX/RX) I use the MSP430G2553's USCI A0 and B0 respectively. In both cases I don't use interrupts which simplifies things considerably.
     
    Upon reset the following steps happen:
    Initialize MSP430 peripherals Initialize packet handler, which will also reset FIFO Initialize and configure of radio, which will also setup SPI Start packet handler, which will also put the radio into receive mode And in the main loop:
    If debug messages are enabled, poll packet handler for status and errors and report them over UART Check FIFO for new packets If there is a new packet, invoke NMEA processing (which sends the message over serial to the PC) and remove packet from FIFO Below follows a more detailed discussion of the radio integration and the implementation of the packet handler.
     
    Radio
    The communication with the radio is vanilla SPI using 4 wires: MOSI (SDI), MISO (SDO), CLK (SCLK) and CS (SEL). I used the MSP430's USCI B0 to implement SPI and a separate pin to control CS.
     
    The only tricky thing to figure out was, that the Si4362 keeps the MISO line floating unless it actively transmits data. This is unfortunate as the master is supposed to poll for a specific response (FF) to detect when the radio is ready to receive more commands. This is easily fixed by adding a weak pull down resistor to SDO. I did this on the board, but it probably also works with using MSP430's internal pull-down.
     
    Additional lines I used to control the radio are:
    SDN to reset the radio CTS, which by default is mapped to the radio's GPIO1, indicating that the radio is ready for the next command While taking up an extra pin, CTS turned out to be much more convenient than the SPI response code to properly time communication flow with the radio. In dAISy, I wait for CTS to go high after each command to ensure the radio completed its task.
     
    The communication protocol is quite extensive but well documented:
    EZRadioPRO API Documentation describes the complete API and all registers AN633 Programming Guide for EZRadioPro Si4x6x Devices describes how to use the API in common scenarios Both are available on the Si4362 product page (link), under Documentation > Application Notes and are still updated quite frequently.
     
    The radio is set up by dumping a large configuration sequence into it. This includes configuration of radio frequency, modulation, GPIO pins and more. This information is stored in radio_config.h, which has to be generated with a tool called WDS (Wireless Development Suite). WDS is available in the Tools section on the Si4362 product site.
     

     
    Above are the settings I used for dAISy. WDS will use this information to configure various amplifiers, filters, clocks and decoding algorithms inside the chip. As Si4362 supports GMSK encoding only indirectly (see this thread), I'm certain there's more optimization potential by tweaking registers, but that's currently way beyond my knowledge of RF theory.
     
    While the Si4362 comes with its own packet handler, it unfortunately does not support NRZI encoding (Wikipedia). So I set up the radio to expose the 9600 baud clock and received data on separate pins and implemented my own packet handler.
     
    Packet Handler
    The packet handler (inspired by Peter Baston's implementation) is implemented as a state machine that is invoked on each rising edge of pin P2.2 which receives the data clock.
     

    There are 5 main states:
    Off, no processing of incoming data Reset, start from anew, either on start up or after successful/failed processing of a packet Wait for Sync, waiting for a training sequence to arrive (010101..) and start flag (01111110), implemented with its own state machine   Reset, start new preamble 0, last bit was a zero 1, last bit was a one flag, training sequence complete, now process start flag Prefetch, ingest the next 8 message bits to ease further processing Receive Packet, process bits until the end flag (01111110) is found or an error situation occurs Independent of state, the interrupt routine continually decodes NRZI into actual bit sequence.
     
    In the "Receive Packet" state there's continuous calculation of the packet CRC and some bit-de-stuffing. When the end flag is found and the CRC is correct, the received message is committed into the FIFO. If an error is encountered, the bytes already written to the FIFO are discarded. In both cases, the state machine starts anew by transitioning into RESET.
    This reads like a lot of code for an interrupt handler. However with the MCU running at 16MHz even the most complex state only uses a fraction (<10%) of the available time.
     
    Future Improvements
    Lastly a list of things I'd like to improve with the next version of dAISy.
     
    Software:
    Receiving on both AIS channels through channel-hopping done 1/5/2014 Tweak radio settings for better sensitivity and lower error rate LED(s) for indicating reception of valid/corrupt packets Hardware:
    Proper antenna connector Layout PCB as BoosterPack and/or USB dongle Receiving on both AIS channels at once with two radio ICs -- edit 12/25: replaced original post with high-level project description, more detailed documentation of implementation to come
    -- edit 12/28: added documentation for hardware (here and on Github), fixed some typos
    -- edit 12/31: added documentation for software and list of future improvements
    -- edit 01/05: implemented channel hopping (change to state machine)
    -- edit 01/15: changed state machine to reflect recent changes (see post further down for details), added link to shared project on OSHPark
    -- edit 01/25: major rework of sync detection state machine

×
×
  • Create New...