Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


tonesenna last won the day on November 24 2012

tonesenna had the most liked content!

About tonesenna

  • Rank
    Advanced Member

Contact Methods

  • Website URL

Profile Information

  • Gender
    Not Telling
  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: 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. 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... 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. 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. It depends on the device and the supply voltage applied to them. Typical maximum frequencies are 8, 16 and 25 MHz. The best to do is actually check the datasheet for the particular device that you're interested in.
  10. 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: 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
  11. 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
  12. Thanks! I searched in forum for "C++" and oddly got zero results. I'l follow your hint though. -- to
  13. 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
  14. 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
  15. It would be nice to have some kind of filter that showed a list of currently unanswered posts, ie, topics with 0 replies. Would such a thing be attainable? Thanks! -- to
  • Create New...