I'm working through the S3 improvements with our engineer, Ben Wirz. Ben provided a chart which shows the current S2 cost breakdown to Parallax. I thought this might be useful to many of us who wonder about product Bill of Material (BOM) costs. Also, keep in mind this has nothing to do with non-recurring engineering (NRE) costs, which can be so much greater than the BOM costs. It'd be far too easy for Parallax to spend $100K in hardware, firmware and GUI redesign and still not reach the starting line with S3 hardware. This is what we have to very carefully manage and consider when making improvements to this kind of product.
Ken, this is very interesting (for bean counter topics). Thank you for sharing this corporately intimate details of yet another product.
Is it possible to come up with cost % (based on current S2 cost, of course) for some of the proposed items? For example, the serial port has BOM costs for the DB9 and some passives, what is the comparable USB costs (connector and FTDI)? This would give an idea of what the BOM cost would be for that change (of course, the redesign work is extra). If a new feature at 10% replaces an existing feature at 1% on the BOM, then it would really need to be a game changer. If getting rid of something saves 1% versus10%, the folks might be willing to make the trade off.
Ken, this is very interesting (for bean counter topics). Thank you for sharing this corporately intimate details of yet another product.
Is it possible to come up with cost % (based on current S2 cost, of course) for some of the proposed items? For example, the serial port has BOM costs for the DB9 and some passives, what is the comparable USB costs (connector and FTDI)? This would give an idea of what the BOM cost would be for that change (of course, the redesign work is extra). If a new feature at 10% replaces an existing feature at 1% on the BOM, then it would really need to be a game changer. If getting rid of something saves 1% versus10%, the folks might be willing to make the trade off.
Hey Rick, yes, absolutely. The next step in this effort is to determine the cost changes (both in design time NRE and BOM costs) for the various features we might add or remove. Then, like an ala carte menu we'll have some ability to pick and choose with consideration to engineering dependencies and values. By the way, the title of this graph says "S3" but it's actually for the S2.
I don't mind sharing any and all of the details, maybe except for our actual unit cost. For some, knowing that an S2 "costs fifty bucks" could make them feel cheated if they pay $129 for it or that "Parallax doesn't deserve to make that much gross profit on each unit". However, if I spent enough time sharing the actual design costs and show how they amortize over a number of units we expect to sell it becomes a lot more clear. The GUI is the potential show-stopper here, too. It'll have to be rebuilt from nothing, and this process will have a substantial cost.
Maybe we should sell S3s "at cost" and get into the subscription service end of things - pay to play, just like an iPhone! Doing things the old fashioned way - boot-strapped - lens a new appreciation to the end result. . .
Ken,
It's frustrating how little people take into consideration development/design costs in judging how much a product costs. They just look at the cost of the various bits and judge it overpriced because their number is well below the price they paid (or would have to pay). It takes a lot of time and work to put all those bits together into a nice package that works and has documentation and software support.
It's even more frustrating when there are people out there undercutting everyone else by not charging for their own development time and labor (or having it subsidised by a big university or whatever). They can't sustain it long term, and they screw up customer expectations for everyone else trying to do things properly.
Anyway, back to the S3! I don't think you should or need to build a new GUI from nothing. It should be based on something pre-existing that can be modified or supplemented with what's needed for S3.
The biggest cost is labor and I see the S2 has several PCBs and a lot of wiring. One option would be to use flex-circuitry for the wiring and the small sensor PCBs.
As I understand it most people would use the S3 as is so why not simplify the design as much as possible to move the selling price closer to $100.
I know not everyone on here understands accounting but Total Cost = Fixed Cost + Variable Cost.
Production tooling, product engineering, and expected profit are all fixed costs while production is a variable cost.
They can't sustain it long term, and they screw up customer expectations for everyone else trying to do things properly.
OT, but that's how I feel about a lot of Kickstarter projects. It's easy to make a great video and overpromise things, especially when you sell a DIY kit where the item's performance depends in large part on the customer's skill . For instance, the smartphone-controlled electric paper airplane kit went viral recently. Great video, simple idea. Everyone has made a paper airplane. Hopefully it's a well-executed product, but in the end, the biggest variable is how the customer made the paper airplane, mounted the kit, and trimmed it (adjusted CG and control surfaces) to fly. Nothing trivial about those. The basic airplane flight quality will make or break this item.
I don't know if there is any feedback or customer interaction after getting a Kickstarter item. If so, I suspect there will be a lot of finger pointing on this one. The disappointed customers blaming the maker, and the maker saying "you didn't make a good airplane".
Sorry I missed this long thread, very enjoyable to read the various comments. I do have some S3 feature requests, things that would have made my workshop development better/richer:
1. The downward facing sensors really need to work in more of a visible spectrum. Unlike the NXT/Lego sensors, the S2 sensors basically can't see black electrical tape, which is the greatly preferred medium for line-following.
2. The forward facing range sensors are easily confused, often report nothing there when it's right in front of a wall. Not sure what the problem is, but it made range and object detection pretty unreliable.
3. I echo the need for a richer programming environment, but not necessarily along the lines of "spin" (a bit geeky for young kids). In particular I REALLY would like to be able to utilize named subroutines, variables, some math functions (for both calculation and branching), inline comments, and more options for moving/turning in tightly controlled closed-loop ways. Most of these things I've been able to do with the Lego/NXT platform, I welcome readers to see the comparable workshop I wrote, have taught, and donated to FIRST: www.rocwnc.org/html/resources.html
I also would like to have some way of lifting the pen, and adding experimental hardware (arms, electronics, etc). I'm sure if I thought about it more other things would surface, but this is my short list.
We're proceeding with the design revisions as discussed in prior pages of this thread.
I've attached our S3 Design Specifications so you can take a look. In a mass produced product such as this one, we have constraints that are difficult to imagine. They include: tooling, BOM costs increases, NRE, rising cost of Asian manufacturing (the S2 is made in 5,000-unit batches in China and would be entirely cost-prohibitive to make in the USA), and design time (between engineering and the factory our "simple" changes could take 6-10 months).
Comments are welcome, appreciated and encouraged!
I think the most important design improvement for the S3 will ultimately be Blockly by Michel. Although our current GUI is so full-featured and very difficult to improve upon, we need multi-platform support at this stage to continue the product.
I started listing the things I liked and found I was about to retype the pdf.
I'm not sure how you'd do it, but I think it would be nice to have a 3.3V source. I'm sure there will be some test point on the PCB like the S2 where I can tap into a 3.3V source but it would be nice if there were a dedicated (and labelled) hole on the PCB for this.
I'm sad to see the RS-232 port go but everyone expects USB these days so I don't see how you can get around this.
I'm glad to see the level shifters go but now there's the concern about protecting the Prop from 5V sources while allowing the full 3.3V logic output. If you place a resistor on the line some 5V devices won't read the 3.3V logic as high. I'd think the best option would be to use the lowest value resistor that would keep the Propeller safe (3K ohm?) . I'd personally would like a way to bypass the resistors but I can always solder my own jumper to do so.
I really like the S3 will be able to recharge the battery internally. I'm starting to type the PDF again. I'll stop here.
I'm glad to see the level shifters go but now there's the concern about protecting the Prop from 5V sources while allowing the full 3.3V logic output. If you place a resistor on the line some 5V devices won't read the 3.3V logic as high. I'd think the best option would be to use the lowest value resistor that would keep the Propeller safe (3K ohm?) . I'd personally would like a way to bypass the resistors but I can always solder my own jumper to do so.
I echo Duane's concerns about protecting the Prop's pin with a 5 volt input.
I like the new specs, Ken. The only thing I would change is the color, from a lemon yellow (an unfortunate association) to something richer.
From this:
To this:
I would recommend Pantone 109 or 115.
Also, stick with the mini-B USB connector, since that's what all your other products use.
I'm also glad that the battery will be removable and easy to swap. This is vital in a classroom situation. IOW, you don't want a student sitting idly while his bot's run-down battery is recharging. It needs to be instantly replacable.
I for one vote we don't rehash the yellow debate. I think that was pretty well covered earlier in the thread. (Not that I disagree with both examples given.)
Edit: It's strange how memory plays tricks. I looked back at the thread to find the yellow discussion was rather limited. I'm off to hide some Easter eggs for myself.
Schools seem to be big on (expensive) multi-unit charging stations, at least for laptops. That could be a lucrative after-market product for the S3's, as well!
First let me take a minute to introduce myself since Im not a regular forum contributor. My name is Ben Wirz. Im an EE by training but dabble in firmware and mechanical design as well. I was the hardware designer for the Scribbler 1 and Scribbler 2. Ill also be designing the hardware for the Scribbler 3. I thought it would be fun to make some regular postings to the forum as my work progresses so the members can see how the design is going and offer any feedback that they might have.
The S3 will offer a number of hardware improvements over the previous versions so I needed to choose a a part of the design to work on first. When tackling a new design, I always try to start working on the hardest part of the design first so that I eliminate as much design risk as possible right at the beginning of the project. For the S3, I chose to work on LiPo rechargeable battery and the associated charging circuitry as the first step. The battery selection has an impact on almost all of the other circuitry so it seemed the logic place to start.
Lets review the electrical design requirements:
The AA batteries will be replaced with a 3.7V lithium polymer (LiPo) rechargeable battery, ideally with a similar capacity to Qty 6 AA NiMh batteries previously used.
The new battery will be housed inside of the existing battery compartment.
A battery charger and power path circuit will be added so that the battery can be charged at the same time the user is programming the robot when connected to a host computer.
The battery can be charged from either a standard USB port at 2.5W or a high power USB port at 7.5W.
The battery will be a super safe type with internal over voltage, over current, over charge and over discharge protection.
A 5V @ 1A step-up power supply will power to the hacker port and other 5V electronics.
A 9V step-up power supply will power to the motor drivers so we can use the same motors as the S2 and also increase the drive speed a bit. More on this in a future posting.
A 3.3V LDO will power the Prop and other 3.3V circuitry.
After performing a survey of the battery charger IC options, I discovered the TI BQ24260 which is an impressive little chip. It will handle USB port type detection, battery charging, power path selection and even give us the boosted 5V supply. The only thing missing from the spec list above are the 3.3V LDO and the 9V motor supply.
The IC is very complex and there is a lot to digest in the data sheet but it looks promising on the surface. I received an evaluation board for the IC today so Ill be building a mockup of the charging system as the next step. In particular, I want to verify that the BQ24260 plays nicely with the FTDI serial convertor IC since they will be sharing the USB bus connection.
I’ve been on a quest to understand USB battery charging for the past few days. It doesn’t sound terribly complex on the surface but there turns out to be a lot more to it than I had originally anticipated. My goal has been an S3 design which supports charging from any of the common USB power sources at the highest current possible. It turns out that are four different types of USB power sources commonly available, listed below for reference.
Standard USB:
5V @ 2.5mA suspended
100 mA unsuspended & configured
500 mA configured (USB 2.0)
900mA configured (USB 3.0)
USB Battery Charging Spec:
Portable Device: 5V @ 1.5A
Charging Port: 5V @ 1.5 A to 5.0 A
USB Power Delivery Spec: This is a newer specification that can supply close to 100W which would be overkill for the S3 needs but it is backwards compatible with standard USB so I will ignore it.
Apple Proprietary: Apple adapters come in a variety of sizes including 5V @ 500mA, 900mA, 1100mA & 2000mA
The device detects the type of USB port that by measuring the voltage of the USB data signal lines when the USB cable is first connected or by detecting shorted data lines. Of course this has to be accomplished in a way that also doesn’t interfere with USB communications. The initial BQ24260 charger IC which I tested only supported Standard & USB Battery Charging adapters. I was disappointed to discover that I couldn’t charge at higher currents from the ubiquitous Apple adapters.
I next tested the TI BQ24295 which supports power detection for all three types of ports. After being stuck at 500 mA charging for the first few days, I was very excited to have the 10W Apple adapter supply 1.8 Amps. But wait, a 10 watt adapter should supply 2 Amps @ 5 V right? It turned out that the adapter was correctly detected but the resistance of the USB power wire caused a large enough voltage drop that the charger IC only received 4.3V at its input under the high load. What’s worse is that the USB spec allows cables with power wires ranging from 28 to 20 AWG gauge. The first cable I tested had 26 AWG wires but a different cable had 28 AWG power wires reducing the current to 1.2Amps!
One last complicating issue is the plug type. Parallax’s products have standardized on the mini USB connector but the USB Battery Charging specification requires a micro USB connector on the device. The micro USB plug also has a reduced contact resistance rating of 30 mOhm versus 50 mOhm of mini USB reducing the voltage drop. We’ll have to use the micro socket for the S3.
It has been an interesting few days of testing and I believe that I have found a good solution with the new charger IC which will meet my goal of the S3 charging and rapidly as possible regardless of the adapter type. The charger IC does not cause any interference while sharing the data bus with the FTDI UART IC but the FTDI interferes with the port type detection. I’ll work on that issue next. The likely solution will be some sort of mux.
I'm hoping the system you come up with will be useful to those of us wanting to make very small production runs or even just one off designs.
I personally like the mini USB connector more than the micro but if that's the way it needs to be. . . Micro USB cables are starting to be almost as ubiquitous as mini USB cables so it shouldn't be hard to find a cable to use.
Great stuff! Thanks for the insight into the complexity of USB charging, the the LiPo battery pack and communication issues. Who knew? Don't know how I missed these updates Ben.
Sounds like some great progress on the S3 though. I agree with erco that your work on the Scribbler family has been fantastic. Looking forward to playing with the next generation! I have used the previous two with Robotic clubs and workshops and they are always well relieved. The Scribbler line is so much robot for so little money and is a great intro to robotics without any need to build. It provides nearly instant gratification, yet has the ability to grow as complex as anyone could want.
Thanks everyone for the kind words and encouragement! It is really rewarding to hear to that others have enjoyed the Scribbler as much as I have.
SLRM - I'm measuring the current supplied by the USB port using exactly the same device as you posted a picture of interestingly enough. In addition to that, I have 3 DMM's connected in ammeter mode. One measures that battery charger / discharge current, one measures the system current and the other measures the 5V booster current. Since the battery charger IC has a step down switcher, the battery charge current can be higher than the USB current if there isn't a large load on the sys or 5V output. I'll post a picture of my test setup later. I'm in the middle of mounting it all to a plate at the moment. It was getting a little too unruly just electrical taped to my desk.
One of the most interesting things that I have found about specific robots, is the
apps and personality. Similar to the Heathkit Hero, and Hero Jr. Interactive personalities
with funtions gave a enticing path to interactivity. Example, a LCD touchscreen on the top of
the robot with apps, like a phone, that someone could run. Apps focused on interaction with the
robot.....
I’m proud to introduce Frank, the world’s first lithium battery powered USB chargeable Scribbler (prototype). I hacked on 4 different development boards to the top of an S2 creating a proof of concept prototype for the future S3 electronics.
[video=youtube_share;mbWMo7GEeCQ]
The development board chips include:
TI BQ24295RGET LiPo Battery Charger & Power Path IC
TI BQ24392RSER USB data switch IC
Analog Devices ADP1614 step up switcher to power the motors at 9 VDC.
FTDI FT231XS USB to Serial Convertor IC
We definitely have a CG problem as result of the lithium pack being much lighter than the AA batteries. I’ve added a bunch of flat washers to the battery compartment as temporary solution. We may need to include a chunk of iron. Even a small amount of bobbing causes false triggers with the line sensors. Aside from this issue, it seems to work quite well. I can charge at the max current from every USB power adapter that I have tried and talk to the Propeller through the USB port. The USB data switch IC prevents the FTDI chip from interfering with the adapter type detection at plug-in.
My next step is to finish creating the schematic for this portion of the S3 design and do more testing. I’ll probably post this part of the schematic after I get it all entered.
Comments
Ken Gracey
Is it possible to come up with cost % (based on current S2 cost, of course) for some of the proposed items? For example, the serial port has BOM costs for the DB9 and some passives, what is the comparable USB costs (connector and FTDI)? This would give an idea of what the BOM cost would be for that change (of course, the redesign work is extra). If a new feature at 10% replaces an existing feature at 1% on the BOM, then it would really need to be a game changer. If getting rid of something saves 1% versus10%, the folks might be willing to make the trade off.
Hey Rick, yes, absolutely. The next step in this effort is to determine the cost changes (both in design time NRE and BOM costs) for the various features we might add or remove. Then, like an ala carte menu we'll have some ability to pick and choose with consideration to engineering dependencies and values. By the way, the title of this graph says "S3" but it's actually for the S2.
I don't mind sharing any and all of the details, maybe except for our actual unit cost. For some, knowing that an S2 "costs fifty bucks" could make them feel cheated if they pay $129 for it or that "Parallax doesn't deserve to make that much gross profit on each unit". However, if I spent enough time sharing the actual design costs and show how they amortize over a number of units we expect to sell it becomes a lot more clear. The GUI is the potential show-stopper here, too. It'll have to be rebuilt from nothing, and this process will have a substantial cost.
Maybe we should sell S3s "at cost" and get into the subscription service end of things - pay to play, just like an iPhone! Doing things the old fashioned way - boot-strapped - lens a new appreciation to the end result. . .
It's frustrating how little people take into consideration development/design costs in judging how much a product costs. They just look at the cost of the various bits and judge it overpriced because their number is well below the price they paid (or would have to pay). It takes a lot of time and work to put all those bits together into a nice package that works and has documentation and software support.
It's even more frustrating when there are people out there undercutting everyone else by not charging for their own development time and labor (or having it subsidised by a big university or whatever). They can't sustain it long term, and they screw up customer expectations for everyone else trying to do things properly.
Anyway, back to the S3! I don't think you should or need to build a new GUI from nothing. It should be based on something pre-existing that can be modified or supplemented with what's needed for S3.
As I understand it most people would use the S3 as is so why not simplify the design as much as possible to move the selling price closer to $100.
I know not everyone on here understands accounting but Total Cost = Fixed Cost + Variable Cost.
Production tooling, product engineering, and expected profit are all fixed costs while production is a variable cost.
OT, but that's how I feel about a lot of Kickstarter projects. It's easy to make a great video and overpromise things, especially when you sell a DIY kit where the item's performance depends in large part on the customer's skill . For instance, the smartphone-controlled electric paper airplane kit went viral recently. Great video, simple idea. Everyone has made a paper airplane. Hopefully it's a well-executed product, but in the end, the biggest variable is how the customer made the paper airplane, mounted the kit, and trimmed it (adjusted CG and control surfaces) to fly. Nothing trivial about those. The basic airplane flight quality will make or break this item.
I don't know if there is any feedback or customer interaction after getting a Kickstarter item. If so, I suspect there will be a lot of finger pointing on this one. The disappointed customers blaming the maker, and the maker saying "you didn't make a good airplane".
1. The downward facing sensors really need to work in more of a visible spectrum. Unlike the NXT/Lego sensors, the S2 sensors basically can't see black electrical tape, which is the greatly preferred medium for line-following.
2. The forward facing range sensors are easily confused, often report nothing there when it's right in front of a wall. Not sure what the problem is, but it made range and object detection pretty unreliable.
3. I echo the need for a richer programming environment, but not necessarily along the lines of "spin" (a bit geeky for young kids). In particular I REALLY would like to be able to utilize named subroutines, variables, some math functions (for both calculation and branching), inline comments, and more options for moving/turning in tightly controlled closed-loop ways. Most of these things I've been able to do with the Lego/NXT platform, I welcome readers to see the comparable workshop I wrote, have taught, and donated to FIRST: www.rocwnc.org/html/resources.html
I also would like to have some way of lifting the pen, and adding experimental hardware (arms, electronics, etc). I'm sure if I thought about it more other things would surface, but this is my short list.
Regards all --
Neil Rosenberg
We're proceeding with the design revisions as discussed in prior pages of this thread.
I've attached our S3 Design Specifications so you can take a look. In a mass produced product such as this one, we have constraints that are difficult to imagine. They include: tooling, BOM costs increases, NRE, rising cost of Asian manufacturing (the S2 is made in 5,000-unit batches in China and would be entirely cost-prohibitive to make in the USA), and design time (between engineering and the factory our "simple" changes could take 6-10 months).
Comments are welcome, appreciated and encouraged!
I think the most important design improvement for the S3 will ultimately be Blockly by Michel. Although our current GUI is so full-featured and very difficult to improve upon, we need multi-platform support at this stage to continue the product.
Ken Gracey
I started listing the things I liked and found I was about to retype the pdf.
I'm not sure how you'd do it, but I think it would be nice to have a 3.3V source. I'm sure there will be some test point on the PCB like the S2 where I can tap into a 3.3V source but it would be nice if there were a dedicated (and labelled) hole on the PCB for this.
I'm sad to see the RS-232 port go but everyone expects USB these days so I don't see how you can get around this.
I'm glad to see the level shifters go but now there's the concern about protecting the Prop from 5V sources while allowing the full 3.3V logic output. If you place a resistor on the line some 5V devices won't read the 3.3V logic as high. I'd think the best option would be to use the lowest value resistor that would keep the Propeller safe (3K ohm?) . I'd personally would like a way to bypass the resistors but I can always solder my own jumper to do so.
I really like the S3 will be able to recharge the battery internally. I'm starting to type the PDF again. I'll stop here.
I echo Duane's concerns about protecting the Prop's pin with a 5 volt input.
From this:
To this:
I would recommend Pantone 109 or 115.
Also, stick with the mini-B USB connector, since that's what all your other products use.
I'm also glad that the battery will be removable and easy to swap. This is vital in a classroom situation. IOW, you don't want a student sitting idly while his bot's run-down battery is recharging. It needs to be instantly replacable.
-Phil
Edit: It's strange how memory plays tricks. I looked back at the thread to find the yellow discussion was rather limited. I'm off to hide some Easter eggs for myself.
-Phil
First let me take a minute to introduce myself since Im not a regular forum contributor. My name is Ben Wirz. Im an EE by training but dabble in firmware and mechanical design as well. I was the hardware designer for the Scribbler 1 and Scribbler 2. Ill also be designing the hardware for the Scribbler 3. I thought it would be fun to make some regular postings to the forum as my work progresses so the members can see how the design is going and offer any feedback that they might have.
The S3 will offer a number of hardware improvements over the previous versions so I needed to choose a a part of the design to work on first. When tackling a new design, I always try to start working on the hardest part of the design first so that I eliminate as much design risk as possible right at the beginning of the project. For the S3, I chose to work on LiPo rechargeable battery and the associated charging circuitry as the first step. The battery selection has an impact on almost all of the other circuitry so it seemed the logic place to start.
Lets review the electrical design requirements:
- The AA batteries will be replaced with a 3.7V lithium polymer (LiPo) rechargeable battery, ideally with a similar capacity to Qty 6 AA NiMh batteries previously used.
- The new battery will be housed inside of the existing battery compartment.
- A battery charger and power path circuit will be added so that the battery can be charged at the same time the user is programming the robot when connected to a host computer.
- The battery can be charged from either a standard USB port at 2.5W or a high power USB port at 7.5W.
- The battery will be a super safe type with internal over voltage, over current, over charge and over discharge protection.
- A 5V @ 1A step-up power supply will power to the hacker port and other 5V electronics.
- A 9V step-up power supply will power to the motor drivers so we can use the same motors as the S2 and also increase the drive speed a bit. More on this in a future posting.
- A 3.3V LDO will power the Prop and other 3.3V circuitry.
After performing a survey of the battery charger IC options, I discovered the TI BQ24260 which is an impressive little chip. It will handle USB port type detection, battery charging, power path selection and even give us the boosted 5V supply. The only thing missing from the spec list above are the 3.3V LDO and the 9V motor supply.The IC is very complex and there is a lot to digest in the data sheet but it looks promising on the surface. I received an evaluation board for the IC today so Ill be building a mockup of the charging system as the next step. In particular, I want to verify that the BQ24260 plays nicely with the FTDI serial convertor IC since they will be sharing the USB bus connection.
Thats about it for today, thanks for reading.
-Ben
I’ve been on a quest to understand USB battery charging for the past few days. It doesn’t sound terribly complex on the surface but there turns out to be a lot more to it than I had originally anticipated. My goal has been an S3 design which supports charging from any of the common USB power sources at the highest current possible. It turns out that are four different types of USB power sources commonly available, listed below for reference.
Standard USB:
5V @ 2.5mA suspended
100 mA unsuspended & configured
500 mA configured (USB 2.0)
900mA configured (USB 3.0)
USB Battery Charging Spec:
Portable Device: 5V @ 1.5A
Charging Port: 5V @ 1.5 A to 5.0 A
USB Power Delivery Spec: This is a newer specification that can supply close to 100W which would be overkill for the S3 needs but it is backwards compatible with standard USB so I will ignore it.
Apple Proprietary: Apple adapters come in a variety of sizes including 5V @ 500mA, 900mA, 1100mA & 2000mA
The device detects the type of USB port that by measuring the voltage of the USB data signal lines when the USB cable is first connected or by detecting shorted data lines. Of course this has to be accomplished in a way that also doesn’t interfere with USB communications. The initial BQ24260 charger IC which I tested only supported Standard & USB Battery Charging adapters. I was disappointed to discover that I couldn’t charge at higher currents from the ubiquitous Apple adapters.
I next tested the TI BQ24295 which supports power detection for all three types of ports. After being stuck at 500 mA charging for the first few days, I was very excited to have the 10W Apple adapter supply 1.8 Amps. But wait, a 10 watt adapter should supply 2 Amps @ 5 V right? It turned out that the adapter was correctly detected but the resistance of the USB power wire caused a large enough voltage drop that the charger IC only received 4.3V at its input under the high load. What’s worse is that the USB spec allows cables with power wires ranging from 28 to 20 AWG gauge. The first cable I tested had 26 AWG wires but a different cable had 28 AWG power wires reducing the current to 1.2Amps!
One last complicating issue is the plug type. Parallax’s products have standardized on the mini USB connector but the USB Battery Charging specification requires a micro USB connector on the device. The micro USB plug also has a reduced contact resistance rating of 30 mOhm versus 50 mOhm of mini USB reducing the voltage drop. We’ll have to use the micro socket for the S3.
It has been an interesting few days of testing and I believe that I have found a good solution with the new charger IC which will meet my goal of the S3 charging and rapidly as possible regardless of the adapter type. The charger IC does not cause any interference while sharing the data bus with the FTDI UART IC but the FTDI interferes with the port type detection. I’ll work on that issue next. The likely solution will be some sort of mux.
-Ben
I'm hoping the system you come up with will be useful to those of us wanting to make very small production runs or even just one off designs.
I personally like the mini USB connector more than the micro but if that's the way it needs to be. . . Micro USB cables are starting to be almost as ubiquitous as mini USB cables so it shouldn't be hard to find a cable to use.
Again, thanks for the updates.
You have done very good work in the past, and no reason to think you will not WOW us with the S3.
Jim
You've done fabulous work on Scribbler and S2. No reason to doubt that S3 will be another instant winner. Can't wait!
Great stuff! Thanks for the insight into the complexity of USB charging, the the LiPo battery pack and communication issues. Who knew? Don't know how I missed these updates Ben.
Sounds like some great progress on the S3 though. I agree with erco that your work on the Scribbler family has been fantastic. Looking forward to playing with the next generation! I have used the previous two with Robotic clubs and workshops and they are always well relieved. The Scribbler line is so much robot for so little money and is a great intro to robotics without any need to build. It provides nearly instant gratification, yet has the ability to grow as complex as anyone could want.
http://www.amazon.com/gp/product/B00DF2485S/ref=wms_ohs_product?ie=UTF8&psc=1
SLRM - I'm measuring the current supplied by the USB port using exactly the same device as you posted a picture of interestingly enough. In addition to that, I have 3 DMM's connected in ammeter mode. One measures that battery charger / discharge current, one measures the system current and the other measures the 5V booster current. Since the battery charger IC has a step down switcher, the battery charge current can be higher than the USB current if there isn't a large load on the sys or 5V output. I'll post a picture of my test setup later. I'm in the middle of mounting it all to a plate at the moment. It was getting a little too unruly just electrical taped to my desk.
-Ben
apps and personality. Similar to the Heathkit Hero, and Hero Jr. Interactive personalities
with funtions gave a enticing path to interactivity. Example, a LCD touchscreen on the top of
the robot with apps, like a phone, that someone could run. Apps focused on interaction with the
robot.....
It’s Alive!!!
I’m proud to introduce Frank, the world’s first lithium battery powered USB chargeable Scribbler (prototype). I hacked on 4 different development boards to the top of an S2 creating a proof of concept prototype for the future S3 electronics.
[video=youtube_share;mbWMo7GEeCQ]
The development board chips include:
- TI BQ24295RGET LiPo Battery Charger & Power Path IC
- TI BQ24392RSER USB data switch IC
- Analog Devices ADP1614 step up switcher to power the motors at 9 VDC.
- FTDI FT231XS USB to Serial Convertor IC
We definitely have a CG problem as result of the lithium pack being much lighter than the AA batteries. I’ve added a bunch of flat washers to the battery compartment as temporary solution. We may need to include a chunk of iron. Even a small amount of bobbing causes false triggers with the line sensors. Aside from this issue, it seems to work quite well. I can charge at the max current from every USB power adapter that I have tried and talk to the Propeller through the USB port. The USB data switch IC prevents the FTDI chip from interfering with the adapter type detection at plug-in.My next step is to finish creating the schematic for this portion of the S3 design and do more testing. I’ll probably post this part of the schematic after I get it all entered.
-Ben
I'll do some screen shots, but someone will be faster than me!
Jim
Well that didn't turn out right.
Trying again.