Jump to content
43oh

chicken

Members
  • Content Count

    908
  • Joined

  • Last visited

  • Days Won

    85

Reputation Activity

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

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

  3. Like
    chicken reacted to igendel in [POTM] dAISy - A Simple AIS Receiver   
    Heh, with this and my oh-so-useful Morse code trainer, we can conquer the market
     
    Thanks for the answer. BTW, your project reminded me a little of this - the bus location/timing signal. Now there's a system the bus faring hacker could really use!
  4. Like
    chicken got a reaction from tripwire in [POTM] dAISy - A Simple AIS Receiver   
    Thanks for shattering my plans for consumer gadget world domination
     
    Technically the range of AIS is about 50 nautical miles, but that requires an unobstructed view and a properly placed and tuned antenna.
    http://www.marinetraffic.com/p/faq#4
     
    With my wimpy dipole antenna (two straight hookup wires) and the wrong impedance matching (50 ohm instead of 73 for a dipole) I was able to receive the packets from the base station 11 kilometers away when in line of sight. When I was parked at the waterfront with the antenna laying on my car's dashboard, I was able to receive messages of ships in line of sight about 2.5 kilometers away and 500 meters when obstructed by buildings.
  5. 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

  6. Like
    chicken got a reaction from bluehash in [POTM] dAISy - A Simple AIS Receiver   
    Ha ha Much less exciting unfortunately. The LaunchPad receives position data from ships and sends the data to a PC where it can be processed and visualized.
  7. Like
    chicken got a reaction from simpleavr in [POTM] dAISy - A Simple AIS Receiver   
    Ha ha Much less exciting unfortunately. The LaunchPad receives position data from ships and sends the data to a PC where it can be processed and visualized.
  8. Like
    chicken got a reaction from igor 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

  9. Like
    chicken got a reaction from Serginho in [Energia Library] Bosch BMP085 Template Library   
    I finished up my first Energia project, a template library for the Bosch BMP085 temperature and pressure sensor. It uses I2C and supports temperature in Celsius and pressure in Pascal.
     
    https://github.com/astuder/BMP085-template-library-Energia
     
    I connected the GY-80 breakout commonly found on eBay, but it should also work with most other BMP085 breakouts, like the ones from Adafruit or Sparkfun.
     
    Note that I had to patch Energia to make 1-byte read work on MSP430G2553 with Rev1.5 LaunchPad. I also had to remove the LED2 jumper, probably due to too weak I2C pull-up.
     
    Update:
     
    Tested on LaunchPad 1.5 with MSP430G2553, StellarPad Rev A and Arduino R3.
     
    Energia requires patches 226 and 235 in twi.c for I2C to work properly on MSP430G2553
    https://github.com/energia/Energia/pull/226/files
    https://github.com/energia/Energia/pull/235/files
     
    Updates:
    - Tested with Energia 0101E0010 with MSP430G2553 and F5529, no more I2C patches needed.
    - Tested with BMP180 and Software I2C http://forum.43oh.com/topic/3777-energia-library-bosch-bmp085-template-library/?p=44410
    - Fixed I2C for Energia 0101E0016 by removing ugly hacks from the past from the library code. Tested only with MSP430G2553
  10. Like
    chicken got a reaction from Apaseo in 1ms Delay function or Similar help   
    _delay_cycles(), at least when working with CCS, might do the job.
     
    As it counts cycles, it's dependent on the CPU clock. For milliseconds, it would look something like this:
    _delay_cycles(MCU_clock_in_Hz / 1000 * wait_time_in_ms);
  11. Like
    chicken reacted to energia in New Energia release 0101E0011 - 12/17/2013   
    I am happy to announce that release 0101E0011 just went up on energia.nu.    I want to thank everybody for their support and contributions. Energia would not have been possible without such an awesome community!   The highlights are: Lots of bug fixes Major update to the CC3000 WiFi BoosterPackLibrary for the MSP430F5529 and TivaC/Stellaris LaunchPad Updated ARM tools to gcc-arm-embedded Initial C2000 support (thanks to Trey German for all his hard work on getting Energia ported to the C2000) CCSv6 Energia Sketch import Support for MSP-EXP430G2 LaunchPad Support for MSP-EXP430F5529LP LaunchPad Support for EK-TM4C123GXL (TivaC) LaunchPad Support for EK-LM4F120XL (Stellaris) LaunchPad Runs on Windows (XP/7/8), Mac OS X and Linux (32/64 bit) Happy Making!
     
    Robert
  12. Like
    chicken reacted to moisesesc in TIVA C Launch Pad Fails at below 0 C and above 40 C temperatures   
    Hello forum members
     
    We have an update on the issues posted here.
     
    After reading all your great suggestions and going back 
     
    and trying to do as suggested, we finally after several hours
     
    of debug and test we were able to ping point the trouble piece of code.
     
    For the low temperature issues it turns out that our equation calculating
     
    fault temperatures was off by factor of 10 as a results when the temperature
     
    return back by ADC at temperatures below 0 was causing our equation to blow up
     
    and trick our code that a temperature fault had occurred on the board and PWM
     
    and motor needed to be shutdown.  Why we did not catch this before, was for two reasons
     
    1) I am a monkey, and failed miserably to code the right equation for the temperature fault.
     
    2) I fail to keep the temperature fault flag longer then a few seconds to allow me to see 
    what had cause the temperature fault.  Now I set up a sticky fault to allow me to see
    what had cause the temperature fault.
     
    Now I am doing more freezer testing and High temperature testing just to make sure I did not guff again.
     
    Thank you so much for all of you that took that time to respond and make great suggestions to try out
     
    and get to a resolution.
  13. Like
    chicken got a reaction from oPossum in TIVA C Launch Pad Fails at below 0 C and above 40 C temperatures   
    Agree on the frustration of getting direct support from large companies, being it TI or others.
     
    Working for a large software company, I know that people are more reactive to reports that already tracked down the exact point of failure as it saves them time. Engineers typically already have their plate full with work for customers with deeper pockets and/or the phone number of the CEO.
     
    That's why I try to dumb things down until it's undeniably clear where the core issue lies. In your case, toggle pins to confirm whether clock variance over temperature is inside or outside spec.
  14. Like
    chicken reacted to moisesesc in TIVA C Launch Pad Fails at below 0 C and above 40 C temperatures   
    chicken,
     
    great points. and by no means am I putting blame on TI, but the fact that they show little interest in helping us
    out directly other than suggesting the forums make me wonder about TI.
     
    Any how.
     
    Here are some details about your crystal stability concerns, which we had the same concerns and even though
    I did not mention this an my previous post, but we have run the firmware using the internal oscillator of the TIVA C pars
    which according to datasheet the internal crystal should be +- 3% through -40 to +85 temperature range with same results.
    The parts fail regardless we run it from external crystal or internal oscillator.
     
    +-3% clock variance should not cause PWM or ADC to drift so bad that it causes Motor to either stop or speed up.
     
    Now, we have spot tested the other components on our board and Launch Pad with Freezing spray while running to see if any other component when spot frozen cause the mention failures.
     
    The only one found to cause problems when expose to low or high temperatures was the TIVA C parts.
  15. Like
    chicken got a reaction from spirilis in TIVA C Launch Pad Fails at below 0 C and above 40 C temperatures   
    I'd try to simplify the test setup before putting the blame on the MCU. From the description above, the system under test is the whole of:
    - custom board or launchpad
    - fairly complex firmware
    - parts outside MCU
    - the MCU
     
    Not saying that it is your fault, but it might as well be the firmware not handling well unexpected timing differences due to faster/slower clock due to temperature change. I would run basic test programs starting with blinking LEDs and then expanding to individual peripherals. E.g. UART communication will be heavily impacted by an oscillator that drifts with temperature.
     
    The operating temperature in the datasheet just means that the chip and peripherals should work under these conditions. From what I can see there's no statement on clock stability etc. relative to temperature.
  16. 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.
  17. Like
    chicken reacted to grahamf72 in Building low power into Energia   
    I've had a little bit of a play, and have made up a few libraries for basic LPM support. These libraries are based on the Energia core files, but take advantage of the fact that the Energia linker gives a higher priority to libraries than to the core, consequently if you add these libraries to your sketch, they will be used seamlessly instead of the core files.  The advantage of doing it this way, is that unless you add the library to your sketch, the standard core files are used, so there's no compatibility issues resulting from modifying the standard core.  I have also designed the routines so that they maintain total compatibility with the existing Energia framework.  Although I don't expect any insidious bugs, the code isn't thoroughly debugged, so if you do choose to use it, it is at your risk.  I have only tested on the 2553 & 2452 - perhaps someone with a 2231 or 5529 could test and modify if they feel so inclined.
     
    My replacement libraries are:
    LPMinterrupts - replaces the core Winterrupts.c.  The inbuilt pin handler now clears LPM bits on exit, so you can go to LPM4 and have your program wake up after a pin interrupt occurs.  Also I've added a couple of functions "waitForAnyPin" and "waitForPin" that allow you to pause execution at a set low power mode until a pin interrupt occurs, with an optional timeout.
     
    crystalWDT - replaces the basic timer core in wiring.c with a version that uses the 32.768 crystal instead of SMCLK. This reduces the resolution of millis & delay, but allows the use of LPM3 timed delays. I have enhanced the delay function to take an optional parameter specifying the low power mode.  In addition I have also added a seconds() function which gives the number of seconds since startup. It takes about 136 years for seconds() to roll over, compared to approx 50 days for millis().
     
    VLOclockWDT - replaces the core wiring.c with a version that uses the internal VLO clock. Again this allows the use of LPM3 timed delays but the VLO clock has poorer resolution and is not nearly as accurate as the standard SMCLK.  I didn't bother with a seconds() function here, as I don't believe the low accuracy of the VLO clock would make it useful.
     
    I have also attached a couple of basic sketches to demonstrate the functions in the libraries.  When I tested I found the following power consumption in the delay and waitForPin functions:
     
    LPM0 - 735uA
    LPM3 - 9uA
    LPM4 - <1uA (my meter read 0)
     
    These are just an idea that I'm throwing out into the open for people to look at, criticise, praise, use or delete as they desire. I'm not suggesting that it be the method ultimately used in Energia (although I'd be very flattered if it is).
     
     
    EDIT: Apparently some people are having trouble opening the zip - if it doesn't work, try the version attached a couple of posts down.
    lpm.zip
  18. Like
    chicken got a reaction from JWoodrell in Coding question, is there an easier way to do this?   
    Try brackets around TestArray, e.g. (long *) (TestArray)[] or some such.
     
    Or you could get fancy and use the union keyword:
    http://en.cppreference.com/w/cpp/language/union
  19. Like
    chicken got a reaction from RobLewis in How to make a ROM image of a sketch for distribution   
    Thanks to @@adrianF for providing the answer to what OP actually asked about.
     
    Yes, changing the oil on my car is easy, but I still prefer to pay a mechanic to do it for me. And I won't try to teach someone how to do it if he/she asks me for a shop's address.
  20. Like
    chicken got a reaction from abecedarian in How to make a ROM image of a sketch for distribution   
    @@abecedarian See! That's what I'm talking about ;-)
  21. Like
    chicken reacted to abecedarian in How to make a ROM image of a sketch for distribution   
    5 qts of oil = $25 oil filter = $5
    container to drain oil into = $5 (<--- one time cost if you keep the pan)
    = $35
     
    Last I checked around here an oil change at a shop cost $69 if you are okay with 5w-30, and $20 extra if you want 20w-50, which I do.
     
    Saving that extra $$$ is worth my time doing an oil change myself.... That's around half off. ;-)
  22. Like
    chicken reacted to David Bender in Building low power into Energia   
    Add the ability to set an arbitrary DCO speed at compile time. Add a DCO calibration option to Energia.
  23. Like
    chicken reacted to adrianF in How to make a ROM image of a sketch for distribution   
    In the "Sketch" menu/drop-down inside of Energia, there are a few simple ways to get to the generated hex file of your compiled sketch. 
    - "Copy Hex file as path" will add the directory path to your hex file to your clipboard
    - "Show compilation folder" will open up your windows explorer to show where all of the compiled files are, including the .hex file
     
    Now that you have the .hex file, users can flash this to a LaunchPad with several tools:
    - For MSP users, there is MSP430Flasher @ www.ti.com/msp430flasher // this tool is lightweight, has the ability to create batch files for simple one-click flashing, etc.
    - For Tiva C users, there is LMFlasher @ http://www.ti.com/tool/lmflashprogrammer
    - There is also the catch-all TI CCS UniFlash @ http://www.ti.com/tool/uniflash
    - And also third party tools such as the one flasher from Elprotronic
     
    Hope this helps!
  24. Like
    chicken got a reaction from danieldlo09 in I can't see a global variable   
    Not sure if that's what confuses the debugger, but you don't need the
    extern int unsigned count declaration in main. 
    You only need extern for variables and functions that are declared in another module, i.e. can't be resolved by the compiler. See
    http://stackoverflow.com/questions/496448/how-to-correctly-use-the-extern-keyword-in-c
  25. Like
    chicken got a reaction from ILAMtitan in Registros P1IN y P1OUT del MSP430g2152 (Registers) Help   
    Looking at the port schematic in the datasheet, you can see that PxIN.y (i.e. bit y of port x) is directly connected to the pad (via a buffer).
     
    So I think by design P1IN always reflects the physical state of the pins, even for pins configured as output. However, changing the state of a pin via P1OUT is only possible when that pin is configured as output.
×
×
  • Create New...