Jump to content
43oh

tonesenna

Members
  • Content Count

    30
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by tonesenna

  1. I attached the design files for this initial version of the rocketfuel. You are free to copy, modify or use it any way, although a reference to the original work would be appreciated.

     

    Prototypes mounted and first tests already done. The charger circuit has one flaw: the body diode of the P-channel MOSFET creates a current path that lets current flow from the battery into the state LEDs and even the charge controller's supply pin.

     

    In practice, we see both leds dimmly lit when the USB supply is removed. This can be somehow circumvented by removind one of the LEDs - the DONE LED, leaving only the indicator of CHARGE in progress.

     

    With this little fix in place, the battery drain is 170uA, well above the expected figure that I estimated, but understandable, due to the current path that isn't currently blocked on the pass transistor.

     

    Here are a few pics of the current prototypes:

    post-28545-0-91811300-1354486820_thumb.jpg

    post-28545-0-77954500-1354486682_thumb.jpg

    post-28545-0-54826400-1354486632_thumb.jpg

     

    I put a post in my blog with some testing I did with only the TPS78233 and the NCP301LSN30T1G.

    You can check it out here: http://wp.me/p2T8F2-11

    I am impressed with the quiescent current of these devices.

     

     

     

     

     

    rocketfuel.sch

    rocketfuel.brd

  2. Good news! :mrgreen:

    Remaining parts arrived today. I have 3 boards assembled, except for the stacking headers, which I'm still waiting to arrive by normal mail.

    Since the sparkfun batteries are also still on transit, I am using an old BL-5B Nokia battery, soldered and soldered wires on it for a quick test.

     

    So far everything looks good. Both the battery and the pass transistor are running very cool (although I'm not sure if the charger is already in CC phase) :thumbup:

     

    It's kinda late so no pictures or test results right now. On the weekend I'll grab a few photos and do some testing.

    Stay tuned.

  3. I discovered 43oh quite recently and had very little experience with the previous forum.

    As for the current implementation I wouldn't say it increased or decreases my commitment to the forum. The same goes for user experience.

     

    For me the main driving factor is the community. The role of the forum software is important in the sense that is doesn't get in the way. I guess that's true for both incarnations.

     

    As for site administration, if this version improves management, filters malicious bots/scripts/whatever and allows more feafures efficiently, that's seriously very cool!! :thumbup:

  4. Hello Everyone,

    I have a little sad news to give, so please bear with me.

     

    The Store will be closing temporarily for personal reasons. As much as I wish to get it back up, I feel that I need to take a step back first. This last month has had me shipping boards almost everyday and alot of transactions coming through. I did not dream of it getting this big. With a lot of transactions taking place both overseas and within the country, I feel that I should setup something formal first.

     

    I feel this is a good time to stop and think. I have boards and inventory. If you have something in mind that you need, please PM me.. I'll try to get it out to you

    Again.. I apologize. Please continue developing your Boosterpacks. For now, members will have to take the initiative and ship these out.

     

    I'll keep you guys posted. Thanks!

     

    On one hand it's sad to know that the store is soaking so much of yout time and effort in such a way that you need to tap the brakes to avoid letting things go out of control.

     

    On the other hand it is very nice to know that you managed to build such a significant community around 43oh and the interwebs as well. Congrats for that.

     

    I really hope you can sort out a way to run the site and store and, also important, take due credit and compensation for all the effort you're investing on the project.

     

    --

    to

  5. Hi everyone,

     

    I am in the process of evaluating which tool might be more suitable for the design of relatively simple boards.

     

    From the alternatives that I found, diptrace and eagle seem to be the top contenders. These are clearly tools not intended for complex jobs, although they can get the thing done for a fraction of the cost of more capable tools.

    • I think eagle has a cumbersome way of defining the coverage of vias with soldermask.
    • The management of component libraries would be better if eagle had an automated way of updating a landpattern accross all libraries that make use of it.
    • We can't mirror the view of the PCB, so that we could see the bottom from below (instead of seing text right-to-left)
    • I whish eagle had a way to design a track ending that could gradualy decrease width up to the point it reaches the pad with the pad's own width (thus not covering 3 pads at once :]
    • Eagle's user interface is well.... a world of its own. It has a steep learning curve, but, once we get the hang of it, it can be used efficiently, specially if we use the command line interface

    These are my rants on eagle, or at least what I can remember now.

     

    I tried diptrace (by trying I mean install and run if for the first time :grin: ) and noticed the following:

    • The library and part chooser in the schematic editor are well... ugly and hardly useable.
    • Some of the dialogues remind me of windows 3.1 (yup, that's right).

    And so I gave up exploring diptrace beyond that point.

     

    I don't care much about builtin component libraries, as I tend to build my own when I need something new for a design.

     

    Whats are your main criticisms about eagle and/or diptrace?

     

    This is not intended to start a flame war or any kind of inflated/passionate standpoints.

    I'd just like to know what are generally known weak points of each tool so that me, and others, know what to count with, when adopting one or the other.

     

    Thanks!

    --

    to

  6. The PCB prototypes arrived today.

    These units come green. However I plan to make them red on the final version.

     

    The PCB quality came quite good in general, although there are some quircks:

    • some drills are slightly off-centre. This can be noticed specially in vias, althouth it's effect is mainly cosmetic
    • There is no soldermask on vias. I have to check the PCB design to fix this
    • silkscreen clearance to copper seems too small apparently. The silkscreen got truncated around some SMD pads, which I wasn't expecting. Need to review my landpattern library.
    • Some placement drills are plated, although I didn't expected them to. PCB was manufactured from an eagle BRD file. Maybe I can fix that using gerbers the next time.

    And now for the mandatory picture... :smile:

    post-28545-0-95778600-1353717236_thumb.jpg

     

    Currently I soldered the BQ2057C and the TPS78233 (Thanks TI, for the samples!!).

     

    The remaining components are on their way and I expect them to arrive next week.

    With some luck I'll be able to make the first test on the following weekend.

     

    --

    to

  7. I second pagibot.

    In a way, any language is unsuited for a particular purpuse if used inappropriately. All those items are generally known as coding/design flaws, regardless of using C, C++, java or any other language.

     

    The question at hand is not if there are people that know C++ and if these people have the skills to code for an MSP430 in C++. The question is about the possibility of using the features of C++ (only the ones that make sense in an embedded world) to code for the MSP430 without compromising performance and code size.

     

    I guess oPossum's links above depict that quite well.

     

    --

    to

  8. Unusual. MSP430 is a classic CISC machine (they call it RISC in the marketing, but that couldn't be more wrong). It has complex instructions that translate simply to assembly programming methods and non-object-oriented C. Basically, it works best when data elements are grouped together, which is anathema to object-oriented programming models. Granted, all CPUs work best this way, but it will make a huge difference on MSP430 ISA. Possibly your C++ compiler is re-arranging data elements, but GCC doesn't typically do this.

    I, for sure, would like to be enlightned on this matter, as it does seem to contradict common kowledge regarding the MSP430 architecture.

     

    I believe that C++, properly used, may be effectivelly used to reduce coding effort and keeping the generated machine code as efficient as the equivalent C would.

     

    It comes to my mind that using templates to code for several implementations of an USCI driver might accomplish that, with a single template one might easilly implement, for instance, an UART on all USCIs of a given device.

     

    --

    to

  9. After many iterations the PCB was *finally* :mrgreen: sent for fabrication.

    This is my first experiment with a PCB prototype so... fingers crossed.

    The prototypes will be green although I'd like to make them red if they happen to spark the interest of the community.

     

    Here's a peek of the final (yup, really) design:

     

    post-28545-0-50671100-1352421887_thumb.png

     

    The boosterpack takes the battery on top to minimize stacking height.

    Components on the solder side were kent away from obstacles (DIP package, jumpers) to minimize stacking height to the least possible.

    There is a 1x2 female header located matching with the VCC connector of the LP. This isn't really necessary, but when mounted enforces the VCC jumper to be removed, virtually eliminating the risk of power supply voltage collision.

    There are shunt resistors that may break the power path to the primary battery holder and the secondary battery connections. This should guarantee that properly mounted the RFBP won't try to recharge a non-rechargeable battery.

    Current monitoring should be trivial using a shunt resistor. For very low power or standby applications we can use a relatively high resistor, in the order of 1kOhm and bypass the resistor when "Running" mode is needed using a jumper. I hope this can come handy to measure current comsumption during standby.

     

    For batteries that lack the JST connector (or In case I mess the pinout :mrgreen: ), there are 3 pads that allow connection to '+', '-' and 'TEMP' terminals of a battery pack.

     

    Can't wait to get the first unit assembled.

     

    --

    to

  10. Last minut changes...

    The original idea was to place the battery beneath the PCB. However, when stacking the RFBP with the LP, the stacking height was too high and forced the use of staching headers that were way too expensive and didn't allow to stack the RFBP with other boards.

     

    So, I'm in thr process of moving all components to the bottom and placing the battery on top. I keep the area of the DIP socket clear so that we can stack boards with only 10mm spacing.

     

    This will allow to keep BOM cost down, make the RFBP stackable and make it more convenient to handle.

     

    --

    to

  11. I never tried this and I could easilly check this for myself.

    But out of curiosity, I wonder if it is possible to code for the MSP430 in C++. In particular I was thinking of mspgcc which is freely available.

     

    Has anyone tried this already?

     

    Thanks.

    --

    to

  12. VLO , DCO and External crystal are all clock generatores. Which one to use depends on your needs in terms of clock speed, accuracy and power consumption.

     

    VLO is a very low power clock that runs in the 10s kHz. While speed is very limited, it provides you a means of having a clock driving some system logic with minimal power consumption. This clock generator isn't accurate at all IIRC.

     

    DCO is a high speed clock generator that runs in MHz range. Is requires more power but allows clock speeds magnitudes higher than VLO. Accuracy is tipical in the range of 1 ~2% so it should be ok for applications that don't rely heavilly on clock accuracy.

     

    Crystal oscilators are the most accurate clock source and probably the most power hungry (except the 32k768 crystal LFXT oscillator). They may provide veri accurate timings and also high clock speeds. On the other hand, crystal oscillators, may require more power than the DCO and probably take longer to wake up from a low power mode than a VLO or DCO oscillator.

     

    MCLK, SMCLK and ACLK ate clocks sourced from each of the above clock generators. The MSP430 may allow you to independently source each clock from each available clock generator and also divide the clock frequency by some desired factor.

     

    By using different clocks you gain flexibility to, for inastance, put the device into a low power mode where MCLK clock source is disabled (power savings yay!!), but VLO may be kept running, driving ACLK which in turn drives a timer that will wake the device some time later.

     

    The MSP430 manual goes into great detail explaining the possible combinations of clock generators and clock signals.

    The datasheed for each device gives you a pretty reasonable figure of power consumption of the chip with each of the clocks running.

     

    --

    to

  13. Things have been advancing slowly but steadily. I made a major review so that I can source all components from the same distributor.

    I also tried to improve power dissipation around the pass transistor so that I can keep operating temperature within reasonable limits.

     

    So, here it is, hopefully the last design iteration of the rocketfuel boosterpack.

     

    post-28545-0-47851300-1351887084_thumb.png

    Top Layer

     

    post-28545-0-82488700-1351887071_thumb.png

    Bottom Layer

     

    post-28545-0-61434300-1351887098_thumb.png

    Silkscreen

     

    --to

  14. Are the bots decoding/guessing captchas?

    A good question would be one that requires some kind of logic from the user which can't be performed by a machine/script.

    In practice, though it's not easy to come up with something, specially something that fits into the tools that ipboard provides.

    One example, would be to select, from a set of objects, the one that doesn't match. The mismatch may be due to colour, number of sides of a polygon, mounting type of a IC package (SMD/TH), type of memory (volatile, non-volatile), prime vs non-prime number, integral power of two vs non integral power, type of object (animal vs fruit), etc etc.

     

    Is this possible to do in ip board? Anything that involves a pool of questions, randomly selected at each test is easilly circumvented by a bot. The ideal would be to have a database of objects that are qualified by a number of properties and on each test, choose a set of objects that would serve such test.

     

    --

    to

  15. Hello Everyone,

     

    - 43oh is getting bigger. I think this is because search engines are finally able to index the forum. Thanks to cube and sirzusa.

    - Most of you here now are familiar how ipboard works. Do you like it? Anything that you don't like in ipboard that phpbb3 has, except that phpbb3 is free?

     

    - I have enough savings from The 43oh Store, to now get an ipboard license. The biggest issue I have now is that legitimate users get stuck in the spam filter and are not able to post links. Ipboard solves this out the box. Also, full width :smile:. The only issue is that we will loose the "Thanks" statistics.

     

    - I'm getting feelers that having three sites is a bit of a hassle for users. In a few months, you will be able to use the same login on all three sites, if that matters.

    --- Is this ok? or will one unified site work? The only problem I see with this is that each community is not about the Launchpad itself, but the chip architecture. Having an LP only site is thinking too narrow.

     

    We had a poll a few months back. Most of you did not care. I'd like to change, but if anyone has a good point not to change, now is a good time.

    Thanks for reading.

    My post is kinda late but I'd like to thank you for the awesome work done with the change to the new forum engine.

    If I had to suggest something I'd go for the colour theme. Personally I'd like it to have a little more contrast, but its just my taste anyway.

     

    Thanks for all your effort!!

     

    --

    to

  16. After moving the battery to the bottom I changed the whole layout.

     

    The battery charger was placed primary battery holder, so that in case I want to build a non-rechargeable version, the non-mounted components stay hidden, for a better visual effect.

     

    post-44998-135135571789_thumb.png

     

    The PCB still needs test points and artwork. After some review It'll be send for prototyping.

     

    I was considering producing the board at eurocircuits. Do you guys have any other suggestions?

     

    --

    to

  17. Yup, I know the connector's P/N and landpattern. My doubt was related with the pinout itself, Which doen't seem to be documented anywhere.

     

    For instance, the 400mAh shows the datasheet here: http://dlnmh9ip6v2uc.cloudfront.net/dat ... 400mAh.pdf

    On page 10 you'll see depicted a 3 pin JST connector that includes the NTC terminal. However, the product page shows a battery with a 2 terminal connector.

     

    I managed to figure out the pinout looking at the pictures on this tutorial: http://www.sparkfun.com/tutorials/241

     

    I don't know if anyone from sparkun reads this forum, but It'd be nice if these folks fixed the documentation for these battery packs.

     

    Currently I'm reviewing the board layout. I hope I can share it soon.

     

    --

    to

  18. So, here's a quick update.

     

    The shunt monitor was dropped because the dynamic range wasn't good enough to cover the range of possible discharge current.

    I made a search for an LDO with very low Iq and UVLO to avoid relying on the battery's own protection circuit and stay on the safe side.

    I couldn't find a suitable part, so I decided to add a voltage supervisor.

    In terms of low power operation I expect the rocketfuel to behave quite well:

    LDO's Iq is 8uA@150mA and 0.5uA@0mA

    Supervisor Iq is 0.5uA @ Vbat=5V

    BQ2057 BAT pin leakage is 1uA typical

     

    Summing all up, the battery drain with no load is expected to be around 2uA, which seems pretty good to me.

     

    I'm also changing the design to use these batteries (eiher 400mAh or 850mAh)

    http://www.tinkersoup.de/product_info.p ... 1576b2246a

    Where can I get the pinout for the connector? Is it standard? I can't find the information anywhere.

     

    Rgds,

    --to

     

     

    Once I update the design I'll post pics here.

  19. Thanks for your input blue, lots of contributions there!

     

    The idea is great, but why do you prefer LiIon over LiPo?

    Lipo cells are very common and well accessible for anybody, and they are flat with capacitys from 350mAh - 1500mAh in a size suited for use with the launchpad. One can stick them to your booster or to the bottom side of the launchpad. Don't get me wrong, you LiIon approach looks very professional in contrast to a LiPo taped to the bottom side of a PCB, but those LiIon round cells are quite bulky.

    I totally agree. My first thought was to use a taped battery. I decided otherwise because I wasn't able to find a battery that would fit the boosterpack with a decent capacity (>400mAh) and with high availability. I want to leave the buttons of the LP available so the bottom side of the boosterpack must be trimmed out. Doing rough math (assuming a 40 pin interface), I have an area of 40mm x 55mm beneath the boosterpack where I might stick a battery with double-faced adhesive tape.

    Do you suggest any website in Europe where I might find this type of batteries? RCR123 is really bulky (availability isn't shiny, either), and that's what's been keeping me back from sending the PCB to build a couple pieces.

     

    For use with the MSP430 Launchpad the LDO is very well suited because of the wide voltage range of the MSP430. If the battery voltage goes below 3.3130V the LDO will go into pass through mode and you can use a full battery cycle. Although you're desing incorporates a protected battery, you might want to add some kind of under-voltage sensing, maybe with the MSP430 itself sensing battery voltage and disabling the LDO if it goes below 3.0V.

     

    I'm not familiar with the C2000 Launchpad, but I know that the Stellaris Launchpad wants 3.3V, so maybe a boost converter would be better suited to utilize a full battery cycle without VOUT dropping below 3.3V. The processor on the Stellaris Launchpad however is rated for Voltages between 2.97V - 3.63V, so if you want to go really low power your LDO design might be superior to a switching regulator.

    If you wan't to support the Stellaris Launchpad, you might consider to use the XL booster pinout because it has 5V broken out, hence you could charge the battery while debugging the Stellaris with a single USB cable. more info on the XL booster interface: http://processors.wiki.ti.com/index.php ... _Interface

    I'll take a look into your suggestion. If I manage to move the battery to the back of the PCB using adhesive tape, the additional PCB area may allow to take some of those aspects into account without compromising low power operation.

     

    EDIT: just stumbled across sparkfun's 'Polymer Litium Ion Batteries'. I'm not sure if they are LiPo, LiIon or sth new, but their physical size is nice: https://www.sparkfun.com/products/339

    If I extend the board area to cover the top (FET) of the LP, this battery would fit nicely. Is there any site based in europe where I might find simillar devices?

     

    Regards,

    --to

  20. Can the charging circuit support a higher capacity battery. Idea looks great otherwise.

    The BQ2057 can handle much larger charge currents, IIRC up to 2A (probably even more because of the external pass device).

    When running from a USB port however, the current must be limited to 500mA. For higher charge rate we'd need an external power input jack and a wall adapter capable of supplying the additional current.

     

    For higher charge currents a switched mode charger might be a better solution. High amperage wall adapters are somewhat rare and probably expensive =)

     

    Regards,

    --to

×
×
  • Create New...