chicken

Members
  • Content count

    869
  • Joined

  • Last visited

  • Days Won

    72

chicken last won the day on May 17

chicken had the most liked content!

About chicken

  • Rank
    Level 4

Profile Information

  • Gender
    Not Telling
  • Location
    Redmond, WA
  • Github
    https://github.com/astuder
  1. That's a nice mock-up. Took me a while to realize that the keypad and display just sit on top of a tin box.
  2. Hi Jens, The breakout while primitive will work as well as the Si446x modules from Ebay/AliExpress. Both will get you started if in line of sight of AIS targets. But I should publish the BoosterPack sometime and update the Github project accordingly. The bandpass filter increases the number of messages received. Range can be better or slightly worse depending on your RF environment. The Si4467 does perform better than the older gen chips (e.g. Si4362-B1B). In real world scenarios the difference can be minor to significant, depending on how marginal AIS reception is. I recently started toying with the EFM32 MCUs. I hope to create a small, inexpensive and easy to integrate AIS module. I really like the dev environment and peripheral libraries. Too early yet to assess RF performance compared to the standalone radios. Regards, Adrian
  3. Now here's a set of fancy booster packs! It's a fully integrated automotive radar. http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/awr/awr-tools-software.page#tools Those rectangles on the right with wiggly traces to the IC are the radar antenna. RF magic! The "CAUTION HOT SURFACE" warning label also promises excitement. Too bad they will cost $299 according to the press release. Posting in the ARM sub-forum as the radar IC features an R4F ARM core. Though the booster packs probably work with beefier MSP430 LaunchPads too. Edit: Here's the mmWave landing page. The AWR also has the non-automotive sibling IWR, including similar booster packs. http://www.ti.com/lsds/ti/sensing-products/mmwave-sensors/mmwave-overview.page
  4. For a bit of background: Atmel AVR (the chip in the original Arduino) has a Harvard Architecture, which separates program memory (i.e. Flash) from data (i.e. RAM). It uses special assembly commands to read program memory. That's why you need to tell the compiler if you want to store a variable in Flash or access data that's stored in Flash. Most other MCUs have a Von Neumann architecture with a unified address space for all types of memory. All access to memory can use the same commands and the compiler decides on where to put things, depending on whether a variable is read-only (Flash) or read-write (RAM). To maintain compatibility with code written for AVR, Energia and other non-AVR Arduino implementations replace progmem related commands to basically do nothing without having the compiler complain too much. For the MSP430 see: https://github.com/energia/Energia/blob/master/hardware/msp430/cores/msp430/avr/pgmspace.h The warning you see is because the replacement for pgm_read_word casts your int to a short. #define pgm_read_word(addr) (*(const unsigned short *)(addr)) If you want to get rid of the warning while keeping pgm_read, you could declare your array as an unsigned short instead of int.
  5. Unless you care about portability to Atmel Arduinos, there's no need to use progmem with Energia. The compiler will put anything that's declared as const into flash memory.
  6. Depending on you environment NULL may not be defined. You can use 0 as alternative. E.g. if ( bar == 0 )
  7. I guess the forward diode is to bypass the 10k resistor when the MCU draws more than 70uA. That's a great trick to remember.
  8. Hi @wanliban Datasheet numbers are hard (impossible?) to hit, especially when the signal comes from a real world target rather than a piece of lab equipment. But you should definitely be able to achieve better than -70 dBm. First thing: What does -70 dBm mean in your setup? The level at which you are able to receive any valid messages? Level at which you receive 50% of all messages? 80%? Real world targets or controlled signal from an RF generator? You can find my radio_config file and software on GitHub: https://github.com/astuder/dAISy Hardware wise, keeping noise out is very important. A bandpass filter in front of the radio helps a lot. Also make sure to minimize the self-inflicted noise by having continuous ground planes in the RF section and keeping the radio away from noisy circuits (like USB). If testing with real-world signals, make sure to use a proper VHF antenna (i.e. not a short rubber duck) and keep the antenna away from other electronics (e.g. monitors or LED and fluorescent light fixtures). Also follow Silabs' procedures for RX LNA matching (AN643) and layout recommendations (AN414) I hope this helps.
  9. I wonder if there's some aggressive compiler optimization going on. The compiler wouldn't know what's happening inside the ROM functions and may put function calls out of order. Maybe worth a try to see if it works with straight calls to the driver lib (i.e. dropping the MAP_ prefix). PS: The reference manual says, that CRC result is available after 1 clock cycle. Also no mention of CRC issues in the errata.
  10. I don't try to convince anybody. I'm way too busy myself to unlearn bare metal C. But I thought the video will be relevant for people that venture down the rabbit hole.
  11. Here's some more C++ magic which seems applicable to embedded programming. I think he optimized for speed instead of space (using tons of mov instead of a loop to initialize sprite bitmaps). But a lot of impressive optimization by the compiler. On the downside, I didn't understand half the constructs he was using. I guess I need to relearn C++ via embedded.fm podcast
  12. On the profile page it is labeled as "content count". Maybe "posts" includes status updates and other content.
  13. no need to start another thread
  14. Is there a specific event when you must read the ADC? If not, just make one main loop that reads keys and ADC. Reading the ADC should only take a fraction of a second.