Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by jpnorair

  1. The quick and dirty way to do it is to use the highest clock speed supported by the lowest core voltage. This information is always in the datasheet. A lot of it comes down to minimizing on-time of peripherals, which tend to have flatter power vs. clock than the CPU has. Edit: in particular, powering the Flash memory.
  2. The uCurrent looks great. People usually tell me about it when I bring-up low current measurements. But the LOG114 is a much better solution if you are an EE willing to wire-up the circuit. That said, there are a lot of EE's on this forum, so I do it for them! LPM3.5 supports interval timing on the Wolverine MSPs, and it looks pretty impressive based on the numbers reported by pabigot, but on the MSP430F5 devices LPM3 is nothing to write home about -- in fact, it's kind of weak. LPM4 on a MSP430F5 has RAM retention, but it's only ~1uA, not especially impressive.
  3. I use a LOG114 EVM board and a scope to measure low currents on MCUs. It's quite ideal for this, because it can measure transitions from the uA range to the mA range in us. Also, for me it has always reported measurements that are bang-on to reference. I would expect the EFM32 to have higher sleep current than RF5969 does, when RAM is being retained, because they are both built on a similar 130nm low-leakage process yet the EFM has more RAM. More RAM = more transistors = more leakage.
  4. The rest of the post should explain that. To clarify: MSP430 doesn't run code as efficiently as CM3 does. The more code that runs, the more advantage a low-power CM3 has. If I run a scheduler or whatnot, that has a tangible impact on power usage. Moreover, running a timer tends to require the ACLK domain is on, which IIRC doesn't allow lower than LPM3. If you have a pure asynchronous app, you can use LPM3.5 and maybe even LPM4. If you are trying to build a sophisticated app with low power, it's like spinning plates to an extreme degree, but for networking "IoT" kinds of things I've
  5. EFM32 has historically been quite expensive, which has prevented most designers I know from using them. Anyway, EFM32 definitely has great features for using with a low power RTOS. If you are simply throwing code onto asynchronous interrupts, MSP430 might work better for you. I should also add that FRAM doesn't really have the same advantage when any sort of timer-based wakeups are used as a critical part of the system (e.g. an RTOS scheduler timer), due to the way the timing and clocking system is architected with the FRAM MSP430s. If you have a system with line interrupts, FRAM can be
  6. Time-based location is tricky. If the location is done by a transmitting tag and a listening infrastructure, which is the low-power way, it is actually called Time-difference of Arrival (TDOA). With only 500kHz bandwidth and a short transmission, the TDOA performance will be OK but not exceptional. I am also skeptical that in 18 months LoRa will be widespread. I would be happy if it were, but telecom doesn't tend to work that way -- nothing is ever "under the radar" in telecom. SigFox has some limited infrastructure in France, but I don't know if it actually is LoRa.
  7. In review, it looks like LoRa uses a proprietary sort of CSS modulation (chirp spread spectrum), although it could be implemented as a sort of MFSK as well -- difficult to say. The basic premise is sound: with good coverage, you don't need mesh routing. Mesh routing is mostly academic, very few production systems use it. At 1kbps, which is roughly the data rate he is using, a sensitive FSK device such as CC1200 or ST SPIRIT1 can actually achieve superior range to LoRa if a good error coding scheme is used. With sophisticated error correction -- maybe not possible on MSP430 but certai
  8. It is a good product. Semtech has a long history of producing excellent low-power RF transceivers. Companies like Semtech do not usually just embark on wild projects like LoRa without someone contracting them to do so, and I don't have confirmation on this, but I am pretty sure that SigFox is who contracted Semtech to design LoRa and the associated transceivers. So, there is an installed base that you can refer-to, which shows at least that the technology works quite well. The main downside of LoRa is that there is not a ton of information about it, so it is going to be difficult to ach
  9. How so? If you're implementing a binary protocol you might as well use a sync word and save yourself a ton of trouble. FF55 is the common one, because UART is inverted and thus FF just looks like a start-pulse, which is easy to set as an edge interrupt. Then you gate on the 55 to weed-out false positives.
  10. FYI: MSP engineering group within TI is also in Germany
  11. Groovy. If by any chance you have one of the STM32F4 or F2 Discovery boards supporting Ethernet, I am very curious about how they compare.
  12. Hmm. This looks like an analog device. The downside here is that 433 MHz is a pretty quiet band, but it is used by various things. If you are only sending raw carrier or a simple tone, you WILL get a lot of false positives on the receiver. I work with very sensitive 433 MHz systems, which this is not, and I do get the occasional false positive -- certainly at least one each 10 seconds of constant-on RX. However, I use a binary correlation scheme to gate packet detection, so with just a simple tone you will want to use a very long tone -- I would say at least 50 ms.
  13. Oooh CMSIS... I think everything that needs to be said has been said. As for what I'm doing right now, I'm doing software. Specifically, getting an OpenTag communication messaging API bridged to a iOS client. iOS via "external accessory protocol" is a giant pain. I'm looking forward to the Android version.
  14. I2C is a good option, certainly more flexible than CAN-bus, but if you don't know what you are doing and have no time, you might want to entertain the offer from Spirilis. You might be worried about power consumption, due to the I2C pull-up resistors. Here's a solution: have the pins go to HiZ input when they are not being used. You can set an edge-detect interrupt to manually detect the START condition, and then quickly wake-up and enable everything as I2C before the START condition is over. The easiest option, however, is to use SPI with two-way chip select. The fundamentals are t
  15. Just a note: CRC is not totally fail-safe. There is a hamming distance that a given code is guaranteed to protect against, over a known payload size. Most implementations of CRC over a variable-length payload are actually broken, though, and their hamming distances are effectively 1. Better to use fixed-length packets or a header with independent CRC protection. The problem is that, if the length byte is in error, the resilience of the CRC goes way down. Other notes: The CCITT variant of CRC16 is lousy. It's the one with polynomial usually represented as 0x1021 ( x^16 + x^12 + x^5 +
  16. For embedded RF, the best way to do it is to have double the Flash necessary, and then just load the new firmware into the other half of flash. Once it is fully loaded, restart. Your bootloader can be tiny, it just needs to jump to the newer half. One thing, however, is that you will need two builds of the firmware: one built to start at offset A and the other at offset B. Another thing you need is a radio layer that is robust against data errors. built-in CRC on the 1101 isn't sufficient unless you are using fixed-length packets. If you are using variable length packets, you need to f
  17. ZigBee is very-much closed source, and many of the specifications aren't freely available either. However, you may be able to buy any-old 802.15.4 receiver with packet sniffing. It will at least expose you to layer 3 and up, while saving you the trouble of dealing with the MAC information. I imagine that a generic 802.15.4 packet sniffer will be relatively cheap.
  18. I'm replying only to this statement, but in the spirit of the topic. MSP430 has an average ALU by MCU-standards. Shifting is fast. Addition is pretty fast too. Multiplication, however, occurs through a peripheral and it is quite slow. It is faster than using a software multiplier, but it is still pretty slow because it does not work through registers. Anyway, often it is much faster to add than to multiply. In particular, one algorithm I wrote once had enormous, enormous, ENORMOUS improvement by taking logarithm (I made a table), then doing additions, then doing antilog (again, a
  19. @@robomon It looks like you are getting some basic computer architecture knowledge with these responses. I cannot underline enough how important basic comp-arch is for computer programming, much less embedded computer programming.
  20. I don't think I am now, because I don't do web. In other words, the advantage of having the HTML/CSS frontend is not an advantage for me. It is something more I would need to learn, and it is non-trivial. But it seems like a very neat implementation of javascript for those who already have a web background. Moreover, there are some examples of node.js implementations for embedded scripting. The reason must be the event-driven aspect of it -- seems logical. In any case, I don't think I will be implementing it. Any sort of scripting implementation I do will be lower-level, simply becau
  21. I assume what you are saying is: NodeJS creates lots of threads. It's interesting to me, though, that people are so fluent in web page markup that it is the easiest path to making a GUI. Don't take this as any sort of criticism, just a remark, because it is a trend despite the massive amount of streamlining that has happened to desktop software IDEs in recent years.
  22. I mostly agree with you, but I was curious what you would say. CoAP started within Sensinode as a reasonably nice little thing. The IEEE balkanized it. I will vouch personally that it is unwise to take a technology through standardization unless it has preexisting commercial success. The standards community can be like a parliament from hell -- you need to be a bit of a dictator to make sure they don't pull your spec in a million crazy directions. Zach Shelby is a bit too nice for it. As far as "too big to fail," CoAP isn't very big outside academia, and by academia I mean a few
  23. CoAP exists, therefore it is infinitely better than is a solution which does not exist. What's wrong with cross layer operations? There are very few widely-used, contemporary implementations of any networking technology that are free of "cross layer hacks." Computer folks (moreso than EEs) tend to worry a ton about making some piece of software easy for other coders, but in the end, obsessive compulsive layering models always seem to make things equally complicated as before, just in other ways, and much less efficient.
  24. I should also mention that it is gradually getting easier to integrate CoAP into designs. CoAP is RESTful, uses UDP, and can run easily on a device with 16 KB RAM. It's possible to run it on a device with only 4KB, but not with the open source code that is easy to use.
  • Create New...