Jump to content
43oh

jpnorair

Members
  • Content Count

    718
  • Joined

  • Last visited

  • Days Won

    18

Reputation Activity

  1. Like
    jpnorair reacted to bobnova in What are you working on today/this week?   
    I've been playing with NRF24L01+ modules and launchpads. I've got 'em to where they can run and send packets on a (&*@#% little solar panel out of a harbor freight solar path light, and make it through the night on a 300mAh NiCd. Next up was improving their range, as the PCB trace antennas aren't especially good (even more so when you have metal walls to punch though, like I do).
     

    Cut traces, soldered mini-coax from a dead WiFi router in place.
     

    Built a mini-yagi!
     

    The test package, a MSP430G2553 launchpad, a JeeLabs AA power board (3.3v boost converter, extremely efficient and low quiescent current), a $1 NRF24 board, and the Yagi.
     
    Works great! Over doubled the range I get through the wall, it went from ~60-80' depending on direction to 200-240'.
  2. Like
    jpnorair got a reaction from spirilis in OSHpark - Swift Service this weekend   
    Cool, thanks for the tip.  I made use of this to spin some antenna test boards.
  3. Like
    jpnorair reacted to spirilis in OSHpark - Swift Service this weekend   
    Saw on oshpark's twitter, orders placed this weekend (2 layer only) will be rushed so they ship out on Friday.
     
    Sent from my Galaxy Note 10.1
  4. Like
    jpnorair got a reaction from rampadc in Oversampling, averaging and getting confused.   
    In radio modulation, which is a course of study with a mountain of research behind it, there is this thing called SNR (signal to noise ratio).  If I decrease the data rate, not only do I increase the amount of energy per bit (the bit is longer, hence it is a bigger pulse), but I also can reduce the amount of noise because the signal is narrower.  So I get bigger SNR.
     
    This is like increasing the duration of the sample.  For the most part, it works great.
     
    In certain cases, however, you will find that there is *frequency dependent interference*.  In other terms, spurious readings you can't avoid, no matter how hard you try.  In RF there is this thing called DSSS (direct sequence spread spectrum) which is really just a way to do controlled sampling and averaging.  However, DSSS has been studied deeply.  Amazingly, it seems to work better than does decreasing the data rate, despite the free space advantage of the latter.  This is simply an artifact of the *real world.*  Granted, DSSS is not simply averaging, it is correlation, but the idea is the same.
     
    Anyway, two cents.
  5. Like
    jpnorair got a reaction from Fred in Free PCBs for OSHW projects   
    Just FYI: this is only a maker thing.  Still, most boards are green by default and no-one cares too much.
  6. Like
    jpnorair got a reaction from bluehash in Airdog Airleash - How does this even work?   
    The way I think of IR, is that IR is just a form of ASK (analog shift keying, or digital AM) using a ~300 THz (Terahertz) carrier frequency.  The antenna for IR can be very small due to the very high frequency.  however, to go a certain distance, the power of the transmission must also be very high.  Interference from daylight poses an additional problem.
     
    Instead, a lower frequency band can be used.  Since the helicopter already needs some from of control interface, it makes sense to me to just use the same interface for distance measuring.  If we really care about accuracy, it is easier to do time-difference-of-arrival (TDOA) and/or time-of-flight measurements using a normal RF band like 433, 900, 2450, etc.
  7. Like
    jpnorair got a reaction from bluehash in Airdog Airleash - How does this even work?   
    The first thing you need to know is that these demo video very likely were done using a human operator of the drone.
     
    There are many ways to get a solution for this problem.  In my opinion, a well-thought image processing stack on the drone could do 90% of the job required, here.  This is probably the part of it that has the most work complete.
     
    Given the large size of the wrist unit, I'm guessing there are quite a few components in it.  It is indicated to contain a Bluetooth Class 1 transceiver, which also necessitates it containing a large battery to source the heavy current demand.  But these things still don't justify the huge size of the unit.  I suspect they may use GPS, gyros, and accelerometer/compass to derive a motion vector, and this is used to instruct the drone where to go.  I would have gone for a different design approach using a dead-simple wrist unit with an RF beacon, angle-of-arrival RF detection on the drone and from there the rest done by image processing on the drone.  But there are usually many ways to skin the cat.
     
    The fact that it has Bluetooth Class 1 indicates to me that these guys are not RF guys.  BT Class 1 has been around for a long time, and it never really caught on -- for good reasons, it doesn't work very well.  Getting >100m range is unusual, there are all kinds of asymmetric issues, etc.  With a "closed loop" app like this and so many long range RF modules popping-up these days, it kind of blows my mind they went with BT -- so I expect the rationale was simply to focus on the other areas where the team has expertise (i.e. not RF).  That's a sensible approach.
  8. Like
    jpnorair got a reaction from abecedarian in Well... crap.   
    Good luck with that!
     
    Vodka sounds like a better plan.  Na zdorovya.
  9. Like
    jpnorair got a reaction from Tibo in M2M shield   
    "This prototype works, but not fully tested : I need a good alimention to supply 2 Amps bursts from the SIM900 during active communication."
     
    Try a LiPoly with a big capacitor.
  10. Like
    jpnorair got a reaction from RobG in What are you working on today/this week?   
    I have been working on "otter," which is a POSIX-C app that interfaces a TTY with a relatively generic packet-based, binary protocol.  Github: jpnorair/otter
     
    With the proper setup, otter can act as a client-side shell, in which the text translations occur on the client rather than the server.  The advantage here is that implementing a classic, text-based shell on an embedded device can consume a ton of resources, but the binary protocols used by otter incur only a modest overhead.  I've implemented some of them on MSP430 and Cortex-M devices.
     
    otter is my first attempt using pthreads, and it was also an opportunity to try building in XCode.  The Clang/LLVM debugging is really, really nice.  I wish desperately for Clang to get more traction with embedded.
  11. Like
    jpnorair got a reaction from rampadc in F550x Breakout Boards   
    BTW: I have a handful of MSP430F5503's in the QFN48... 50 I think.  I'll sell the lot for $100 if you are interested.
     
     
    The best-practice here is to put a 100nF cap next to each Vcc pin to suppress voltage transients.  You can additionally put the 4.7uF cap near any one of the Vcc input pins.
     
    Near AVcc, sometimes they like you to provide an additional capacitance for noise suppression.  It should be near the AVcc pin.
  12. Like
    jpnorair got a reaction from emdarcher in Hi from San Francisco!   
    I'm wikipedia-ing.  Your high school's previous location (before 1962, it seems) is very close to where I live.
     
    I'm not actually "from SF," but I do live here.  I have few secrets: I'm ~33 years old and I'm an electrical engineer.  I'm not much of a "maker" because it's my job to make things, so I don't have too many projects worth posting online.
     
    If you want a piece of advice, I think you should program MSPs in assembly.  Anything you do now is mostly for the learning experience.  All the top EEs I know have a firm command of computer architecture and optimization even if they don't really do computer stuff.  Eventually you will find yourself in a computer architecture class, and the assembly experience will be worth something.  In the professional world, understanding the ISA will make your C better, anyway.
  13. Like
    jpnorair got a reaction from Rei Vilo in Anyone using TI-RTOS?   
    I blasted through the modules.  By "blasted" I mean that I fast forwarded through the slides, but I'm an embedded RTOS expert, so to speak, so this was enough.
     
    It's clear TI has sunk a *ton* of money into this.  Mostly that's a good thing.  On the other hand, it's also clear that all of the tools they have built are designed to prevent you from ever porting or easily using it with anything other than a TI chip.  I would be really careful with that, because things happen in the semiconductor industry, and TI isn't always where you want to be (sacrilege... I know).  If you have a goal to do something on the extreme side, e.g. *lowest power* or *cheapest* or *fastest frame rate* (etc) or some other extreme performance metric, by no means do you want to use this.  In that case you need something more portable.  Otherwise, no big deal, you can probably stay inside the TI stable without trouble.
     
    Another thing I noticed is that TI-RTOS is fairly well abstracted across HW.  This means that it either has multiple, *very different* ports or that it is equally crappy on all the platforms.  I'm not sure which.  As a side-note, you can find embedded RTOSes that started with MSP430, others that started with Cortex-M, others that started with 8bit archs.  There's a legacy that makes them optimized for the original arch.  Contiki 3, for example, is in development and undergoing a massive effort to move all the legacy AVR8 ideology into ARM-CM ideology.  The take-home message is that it's a massive effort.  ChibiOS is CM-centric.  OpenTag is an exokernel (and a big mess) with entirely separate kernels for the different archs it supports, but nonetheless there's a clear MSP lineage.  Considering the  hoopla on nested interrupts, I wonder what was the origin of TI-RTOS (SYS/BIOS).  No-one targeting ARM is going to make a fanfare about nested interrupts.
     
    Finally, my most important piece of advice is also the one I made first: don't put I/O drivers in tasks (or threads).  Module 3 discusses the implementation of an 100kHz Audio driver inside a task.  GAG.  This means the scheduler is going to run *A LOT*.  Since it is a tickless scheduler, it also isn't a small piece of code.  Just be aware of that.  I'm not sure this is the best ideology for low speed MCUs.  What I do is build a driver that exists outside the scheduler, and when it completes enough I/O to qualify as a "packet," it will preempt the task which processes the packet.  This is very efficient, because the scheduler only has to run once per packet.  It is harder to write the driver, sure, but often this is the difference between something working and not-working on a chip like MSP430.
  14. Like
    jpnorair got a reaction from Automate in Anyone using TI-RTOS?   
    I blasted through the modules.  By "blasted" I mean that I fast forwarded through the slides, but I'm an embedded RTOS expert, so to speak, so this was enough.
     
    It's clear TI has sunk a *ton* of money into this.  Mostly that's a good thing.  On the other hand, it's also clear that all of the tools they have built are designed to prevent you from ever porting or easily using it with anything other than a TI chip.  I would be really careful with that, because things happen in the semiconductor industry, and TI isn't always where you want to be (sacrilege... I know).  If you have a goal to do something on the extreme side, e.g. *lowest power* or *cheapest* or *fastest frame rate* (etc) or some other extreme performance metric, by no means do you want to use this.  In that case you need something more portable.  Otherwise, no big deal, you can probably stay inside the TI stable without trouble.
     
    Another thing I noticed is that TI-RTOS is fairly well abstracted across HW.  This means that it either has multiple, *very different* ports or that it is equally crappy on all the platforms.  I'm not sure which.  As a side-note, you can find embedded RTOSes that started with MSP430, others that started with Cortex-M, others that started with 8bit archs.  There's a legacy that makes them optimized for the original arch.  Contiki 3, for example, is in development and undergoing a massive effort to move all the legacy AVR8 ideology into ARM-CM ideology.  The take-home message is that it's a massive effort.  ChibiOS is CM-centric.  OpenTag is an exokernel (and a big mess) with entirely separate kernels for the different archs it supports, but nonetheless there's a clear MSP lineage.  Considering the  hoopla on nested interrupts, I wonder what was the origin of TI-RTOS (SYS/BIOS).  No-one targeting ARM is going to make a fanfare about nested interrupts.
     
    Finally, my most important piece of advice is also the one I made first: don't put I/O drivers in tasks (or threads).  Module 3 discusses the implementation of an 100kHz Audio driver inside a task.  GAG.  This means the scheduler is going to run *A LOT*.  Since it is a tickless scheduler, it also isn't a small piece of code.  Just be aware of that.  I'm not sure this is the best ideology for low speed MCUs.  What I do is build a driver that exists outside the scheduler, and when it completes enough I/O to qualify as a "packet," it will preempt the task which processes the packet.  This is very efficient, because the scheduler only has to run once per packet.  It is harder to write the driver, sure, but often this is the difference between something working and not-working on a chip like MSP430.
  15. Like
    jpnorair got a reaction from spirilis in Anyone using TI-RTOS?   
    I blasted through the modules.  By "blasted" I mean that I fast forwarded through the slides, but I'm an embedded RTOS expert, so to speak, so this was enough.
     
    It's clear TI has sunk a *ton* of money into this.  Mostly that's a good thing.  On the other hand, it's also clear that all of the tools they have built are designed to prevent you from ever porting or easily using it with anything other than a TI chip.  I would be really careful with that, because things happen in the semiconductor industry, and TI isn't always where you want to be (sacrilege... I know).  If you have a goal to do something on the extreme side, e.g. *lowest power* or *cheapest* or *fastest frame rate* (etc) or some other extreme performance metric, by no means do you want to use this.  In that case you need something more portable.  Otherwise, no big deal, you can probably stay inside the TI stable without trouble.
     
    Another thing I noticed is that TI-RTOS is fairly well abstracted across HW.  This means that it either has multiple, *very different* ports or that it is equally crappy on all the platforms.  I'm not sure which.  As a side-note, you can find embedded RTOSes that started with MSP430, others that started with Cortex-M, others that started with 8bit archs.  There's a legacy that makes them optimized for the original arch.  Contiki 3, for example, is in development and undergoing a massive effort to move all the legacy AVR8 ideology into ARM-CM ideology.  The take-home message is that it's a massive effort.  ChibiOS is CM-centric.  OpenTag is an exokernel (and a big mess) with entirely separate kernels for the different archs it supports, but nonetheless there's a clear MSP lineage.  Considering the  hoopla on nested interrupts, I wonder what was the origin of TI-RTOS (SYS/BIOS).  No-one targeting ARM is going to make a fanfare about nested interrupts.
     
    Finally, my most important piece of advice is also the one I made first: don't put I/O drivers in tasks (or threads).  Module 3 discusses the implementation of an 100kHz Audio driver inside a task.  GAG.  This means the scheduler is going to run *A LOT*.  Since it is a tickless scheduler, it also isn't a small piece of code.  Just be aware of that.  I'm not sure this is the best ideology for low speed MCUs.  What I do is build a driver that exists outside the scheduler, and when it completes enough I/O to qualify as a "packet," it will preempt the task which processes the packet.  This is very efficient, because the scheduler only has to run once per packet.  It is harder to write the driver, sure, but often this is the difference between something working and not-working on a chip like MSP430.
  16. Like
    jpnorair got a reaction from Fred in Anyone using TI-RTOS?   
    I blasted through the modules.  By "blasted" I mean that I fast forwarded through the slides, but I'm an embedded RTOS expert, so to speak, so this was enough.
     
    It's clear TI has sunk a *ton* of money into this.  Mostly that's a good thing.  On the other hand, it's also clear that all of the tools they have built are designed to prevent you from ever porting or easily using it with anything other than a TI chip.  I would be really careful with that, because things happen in the semiconductor industry, and TI isn't always where you want to be (sacrilege... I know).  If you have a goal to do something on the extreme side, e.g. *lowest power* or *cheapest* or *fastest frame rate* (etc) or some other extreme performance metric, by no means do you want to use this.  In that case you need something more portable.  Otherwise, no big deal, you can probably stay inside the TI stable without trouble.
     
    Another thing I noticed is that TI-RTOS is fairly well abstracted across HW.  This means that it either has multiple, *very different* ports or that it is equally crappy on all the platforms.  I'm not sure which.  As a side-note, you can find embedded RTOSes that started with MSP430, others that started with Cortex-M, others that started with 8bit archs.  There's a legacy that makes them optimized for the original arch.  Contiki 3, for example, is in development and undergoing a massive effort to move all the legacy AVR8 ideology into ARM-CM ideology.  The take-home message is that it's a massive effort.  ChibiOS is CM-centric.  OpenTag is an exokernel (and a big mess) with entirely separate kernels for the different archs it supports, but nonetheless there's a clear MSP lineage.  Considering the  hoopla on nested interrupts, I wonder what was the origin of TI-RTOS (SYS/BIOS).  No-one targeting ARM is going to make a fanfare about nested interrupts.
     
    Finally, my most important piece of advice is also the one I made first: don't put I/O drivers in tasks (or threads).  Module 3 discusses the implementation of an 100kHz Audio driver inside a task.  GAG.  This means the scheduler is going to run *A LOT*.  Since it is a tickless scheduler, it also isn't a small piece of code.  Just be aware of that.  I'm not sure this is the best ideology for low speed MCUs.  What I do is build a driver that exists outside the scheduler, and when it completes enough I/O to qualify as a "packet," it will preempt the task which processes the packet.  This is very efficient, because the scheduler only has to run once per packet.  It is harder to write the driver, sure, but often this is the difference between something working and not-working on a chip like MSP430.
  17. Like
    jpnorair got a reaction from timb in Adding CC430 support   
    Cool.  The stock Chronos 433 antenna is absolute rubbish, though, so it is a low bar.
     
    In any case, I can mail you a hand-built ~5cm reference monopole, if you want to compare RSSI readings (send me a PM).  I have tons of these, which I manufacture in the lab.  Normally I don't offer this sort of thing, but you are actually working on something that is of interest to me.  The same offer goes towards anyone doing 433 MHz Chronos work, or for that matter CC430, CC11xx, and CC1200 work.
     
    It's also important to mention that a single-ended antenna (monopole) needs a decent-sized ground plane to work properly.  The Chronos doesn't offer this, but if it is plugged-in to a USB cable or some other path to mains-power, this will serve as an excellent ground (even plugged into a battery powered laptop, smartphone, etc, this is plenty of grounding).  As soon as you remove this ground, the antenna performance will get much worse.  Ideally your ground plane on a monopole configuration has radius of quarter-wave, but if you don't need wide bandwidth you can hack a decent antenna system just by having the perimeter of the ground plane >= half-wave (in this case, you are actually building a dipole).
  18. Like
    jpnorair got a reaction from cubeberg in 43oh badge   
    It looks great!  Somehow, one of us is going to need to get a good video of the persistence-of-vision display in action.  Maybe someone here knows how to get good video of this sort of thing, but I certainly do not.
  19. Like
    jpnorair reacted to cubeberg in 43oh badge   
    This project was a collaboration with Texas Instruments.  I've kept it hush-hush so far, but as of yesterday - it's finally out in the wild!  Yesterday at the SF Maker Faire, Texas Instruments started giving away boards at their booth.  If you're visiting the Maker Faire today - please drop by booth 220!
     
    Thanks a ton to TI for sponsoring and feedback on the design.  Will Cooper, Adrian Fernandez, Mark Easley, Dung Dang and Rachel Platis were all involved - this wouldn't have happened without them.
    Also - Elecrow did a wonderful job on the boards and initial kitting (I added the batteries and MCU once back in the US).  
     
    Badge page on 43oh - http://43oh.com/badge/  (drop by this page for more info and an intro video).
    Github with schematics, sample code, etc. : https://github.com/dd430/430RocketBadge
     
    The board is intended to be easy to solder - parts were kept to a minimum.  It showcases several features of the MSP430G line.  The board has a Cap Touch slider as well as 5 LEDs.  The pre-programmed demo starts in a POV mode.  If you swing the badge in a circle, you'll see the pre-programmed messages written in the air.  My favorite part of the project though - has to be the ability to update the message on the badge via the light sensors on the board.  You may have seen similar projects.  One sensor is used for the clock, another for the data.  A simple web page allows design of a message and then uses two squares on the page to trigger high/low values on the light sensors.  You can find it at the 43oh badge page above.
     
    All in all - we were able to get 500 kits created.  Hopefully these will be given away at events that TI is attending for quite a while.  I'll post back if I hear they're going to show up for an event.  Hopefully we'll also have a few to give away to forum members as well.  
     
    BTW - I will say - creating 500 kits of something is a significantly different endeavor than just a handful
     
    Boards after manufacture:

     
    500 kits arrived at my house:

     
    I started with several ideas for the board initially - but we ultimately ended with the POV design.  V1 of the design used a shift register to control the LEDs and took significantly longer to solder.  Not the best for a beginner kit  Not to mention getting the clock working with the shift register was a bit squirly for some reason.
     
    V1 badge vs V2

     
  20. Like
    jpnorair got a reaction from abecedarian in Adding CC430 support   
    Cool.  The stock Chronos 433 antenna is absolute rubbish, though, so it is a low bar.
     
    In any case, I can mail you a hand-built ~5cm reference monopole, if you want to compare RSSI readings (send me a PM).  I have tons of these, which I manufacture in the lab.  Normally I don't offer this sort of thing, but you are actually working on something that is of interest to me.  The same offer goes towards anyone doing 433 MHz Chronos work, or for that matter CC430, CC11xx, and CC1200 work.
     
    It's also important to mention that a single-ended antenna (monopole) needs a decent-sized ground plane to work properly.  The Chronos doesn't offer this, but if it is plugged-in to a USB cable or some other path to mains-power, this will serve as an excellent ground (even plugged into a battery powered laptop, smartphone, etc, this is plenty of grounding).  As soon as you remove this ground, the antenna performance will get much worse.  Ideally your ground plane on a monopole configuration has radius of quarter-wave, but if you don't need wide bandwidth you can hack a decent antenna system just by having the perimeter of the ground plane >= half-wave (in this case, you are actually building a dipole).
  21. Like
    jpnorair got a reaction from Automate in Adding CC430 support   
    Cool.  The stock Chronos 433 antenna is absolute rubbish, though, so it is a low bar.
     
    In any case, I can mail you a hand-built ~5cm reference monopole, if you want to compare RSSI readings (send me a PM).  I have tons of these, which I manufacture in the lab.  Normally I don't offer this sort of thing, but you are actually working on something that is of interest to me.  The same offer goes towards anyone doing 433 MHz Chronos work, or for that matter CC430, CC11xx, and CC1200 work.
     
    It's also important to mention that a single-ended antenna (monopole) needs a decent-sized ground plane to work properly.  The Chronos doesn't offer this, but if it is plugged-in to a USB cable or some other path to mains-power, this will serve as an excellent ground (even plugged into a battery powered laptop, smartphone, etc, this is plenty of grounding).  As soon as you remove this ground, the antenna performance will get much worse.  Ideally your ground plane on a monopole configuration has radius of quarter-wave, but if you don't need wide bandwidth you can hack a decent antenna system just by having the perimeter of the ground plane >= half-wave (in this case, you are actually building a dipole).
  22. Like
    jpnorair got a reaction from DKrepsky in nrf24l01+ increasing distance   
    For a monopole antenna, the resonant length is 0.25 * wavelength.  The frequency is 2450 MHz, so the wavelength is: c/f, where "c" is speed-of-light and f is Hz.  In other words, 300000000 / 2450000000 = wavelength in meters.
     
    A normal monopole has impedance of 37 Ohms, which will match reasonably well with your board.  However, you need to trim the antenna more than wave/4 because there is always capacitance and inductance in non-ideal wires.  It is causing the actual wavelength to be shorter than the free-space wavelength.  The best way to get your tuning optimized in with a vector-network-analyzer (VNA).  If you don't have one (I can't imagine you do), you can do it experimentally as described above.
     
    The dipole configuration described above is a balanced antenna, so it is more reliable than a monopole is.  Monopoles depend on the grounding of the device, dipoles do not.  If your board has a small ground plane or bad grounding, the monopole will have poor performance.  So, I usually recommend half-wave (i.e. dipole) antennas if possible.
     
    If you want to get really clever, you could try to improve the tuning by constructing a monopole "inverted-F antenna" (IFA), but I would hold-off on that -- maybe a second project.
  23. Like
    jpnorair got a reaction from fatihinanc in Code Composer Studio v6 now officially released   
    It's a shame it doesn't support OS X.  You think TI would have figured-out that in the last 5 years, virtually all software devs in the USA have switched to Mac, and this represents a lot of the hobbyist community.  I use a mac for my personal laptop, and if CCS were available to run natively I might muck around with MSP430 on the weekends.  Oh well, maybe v6.1.
  24. Like
    jpnorair got a reaction from Yendi in Drilling mounting holes in MSP430 PCB   
    TI releases PDFs of the copper layers for most of their dev kits.  You can find these documents on the TI webpages for each dev kit in question.  You can probably figure out how to overlay these images in an image program and search for open spaces.  Also, it most cases you aren't going to hurt anything by drilling through a ground plane or ground pour.
  25. Like
    jpnorair got a reaction from bluehash in KickSat -- Your personal spacecraft in space!   
    Here is an overview.
    http://rampac.energy.gov/docs/rfid/RFID-INMM09.pdf
     
    Edit:
    Here is an article specifically describing the irradiation process. (see page 42)
    http://rampac.energy.gov/docs/rfid/Paper1.pdf
×
×
  • Create New...