6502.org Forum  Projects  Code  Documents  Tools  Forum
It is currently Sun Nov 24, 2024 9:59 am

All times are UTC




Post new topic Reply to topic  [ 15 posts ] 
Author Message
 Post subject: Reliability (oops?)
PostPosted: Mon May 17, 2021 11:05 am 
Offline
User avatar

Joined: Wed Feb 14, 2018 2:33 pm
Posts: 1488
Location: Scotland
Nothing new, but after my recent house move I've found my Ruby816 board to appear to be a little less reliable than before - the reason appears to be supply voltage.

I normally power it from a USB socket on my desktop PC (which also is the serial line) but after my move, I changed the sockets round to better suit the new location and other USB peripherals and found the voltage dropped to 4.46v when I plugged my GoPro camera into the same set of outlets on the front of the PC.

I used to use the rear outlets for my Ruby boards previously which were directly off the motherboard but the front ones are on a cable off a small "daughter" board which is typical for desktop PCs. Remove the GoPro and the voltage goes up to 4.7v which while not ideal is just enough to run the board reliably.

Oddly, the 'failure' was for the 65c816 side of the board to simply stall while the ATmega side carried on working. I've not had a chance to start probing to see what the issue really is - possibly the worlds longest wait-state for a WDC chip ;-)

-Gordon

_________________
--
Gordon Henderson.
See my Ruby 6502 and 65816 SBC projects here: https://projects.drogon.net/ruby/


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Mon May 17, 2021 3:58 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
I have a healthy mistrust of all things USB. The specification of USB Power Delivery is around 700 pages; the download is around 50MB and contains several MB of documented changes from previous specs... Amazingly, it allows a device to ask for a specific voltage and current and adjust it in small increments; I am not sure what happens to other devices on the same hub (having not read the spec).

In practice I found my system's USB ports very unreliable as power goes. I had devices that worked in some ports and not others. Voltage drops under load are likely, and I suspect that I had damaged some internal hubs with high current demands.

USB 3.0 is capable of much more power than previous versions, and will likely deliver a better supply.

Similarly, wall-wart USB power 'chargers' are all over the place with regulation, voltage and current. It is particularly hard to find one that provides more than 1A consistently, as there is a lot of fakery.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Mon May 17, 2021 4:41 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
Yes, USB can be a bit tricky, depending on what you're using it for... and the spec keeps evolving. In general, I always a FTDI USB-to-UART adapter to get a functional serial port for a console on my SBC projects (USB powers the FTDI interface only). However, I also provide a separate power supply connection and use a good quality regulated supply, usually of the wall-wart variety and a switching type which has a fairly wide input voltage range. Output current is usually 2.5 to 3.0 amps, which is adequate. I also prefer a supply which outputs around 5.1VDC.

I have done a fair amount of testing using a USB port to power my SBC projects, but never quite like the results. In most cases, the USB port doesn't cope well with the turn on surge, as there can be 3-5 filter capacitors, each rated at 68uF. This results in some current-limiting function of the USB port and the SBC resets twice until the voltage level stabilizes. The available voltage and current will vary from machine to machine (desktop, laptop, brand, age, etc.)

I did find a neat diagnostic tool from Tripp-Lite however... so I'll be adding one to my next Mouser or Digikey order. It will show active voltage and current draw of the USB port it's plugged into (device in use plugs into it).

Attachment:
t050001usba.pdf [157.54 KiB]
Downloaded 48 times

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Mon May 17, 2021 5:36 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
drogon wrote:
Nothing new, but after my recent house move I've found my Ruby816 board to appear to be a little less reliable than before - the reason appears to be supply voltage.

I normally power it from a USB socket on my desktop PC...

I'm amazed it works at all. The phrase "USB power" is a bit of an oxymoron, as a USB 2.0 port is rated for 2.5 watts maximum—USB 3.0 is rated for 4.5 watts maximum. In my book, that's not "power."

The problem is although those numbers seem to be adequate to power one of our homebrew systems, the reality is very little headroom is available for the momentary demand spikes that occur as SRAM, EPROM, etc., are selected and read/written. Also, as enso noted, regulation leaves something to be desired, something that isn't improved by funneling the current through the very small gauge wires in a USB cable.

You should consider powering Ruby with an actual power supply, one that is "stiff" enough to hold Vcc right at 5 volts (or whatever you are using). I'd also beware of wall warts, which are not noted for sterling performance as well.

Lastly, I'm quite suspicious of the need to use hundreds of pages to describe how to provide some power to a USB device. We're not talking kilowatts here.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Mon May 17, 2021 5:42 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
A few years ago my boss asked me to design a charger for three series lithium batteries from a microUSB connector. (The circuit was to kick the voltage up, monitor the state of charge of each cell by itself, and balance them, report the state of charge of the stack, have time-out, and other things.) Without involving any intelligence to negotiate the higher powers, a USB port is supposed to give 5V and up to half an amp. Without using an actual USB port, I connected to the bench power supply to try my breadboarded circuits, and found that common, thin USB cables with tiny connectors cannot do it. I had originally made my circuit limit the input current to 500mA, but the voltage sagged so much (down to 3V) that the PIC16 controlling the charging and other things would not run if the unit was off such that battery power was not reaching the PIC, or unless the batteries were charged such that the USB current was quite low. I had to limit the input current to 250mA, making it take a lot longer to charge these batteries. (I also made it so the presence of input voltage would turn on the battery power to a 5V regulator to feed the PIC, even if the main electronics were still turned off.) There are plenty of reasons I don't like USB.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Mon May 17, 2021 6:15 pm 
Offline
User avatar

Joined: Thu Dec 11, 2008 1:28 pm
Posts: 10986
Location: England
> In most cases, the USB port doesn't cope well with the turn on surge, as there can be 3-5 filter capacitors, each rated at 68uF. This results in some current-limiting function of the USB port and the SBC resets twice until the voltage level stabilizes.

Hmm, is there any clever circuit design technique, I wonder, which would allow for enough effective capacitance on a board but somehow not involve such a surge at power-on?


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Mon May 17, 2021 7:17 pm 
Offline
User avatar

Joined: Tue Mar 05, 2013 4:31 am
Posts: 1385
BigEd wrote:
> In most cases, the USB port doesn't cope well with the turn on surge, as there can be 3-5 filter capacitors, each rated at 68uF. This results in some current-limiting function of the USB port and the SBC resets twice until the voltage level stabilizes.

Hmm, is there any clever circuit design technique, I wonder, which would allow for enough effective capacitance on a board but somehow not involve such a surge at power-on?


Perhaps, moving one of the filter caps to the 5V input (unswitched) would help. There's also the chance that decreasing the number of total filter caps and/or using a smaller capacitance value might alleviate the problem. I'm currently using polymer electrolytic caps, but in my next SBC (which is planned for mostly SMT components) might switch to SMT Tantalum parts.

In general, I tend to go with multiple filter/reservoir caps and a fair number of bypass caps for each component. For me, it's being safer than taking on the risk for noise related problems. Another future option is to move to 3.3V designs. This would allow a small and efficient 5.0 to 3.3V LDO regulator, which (hopefully) shouldn't be a problem to run from USB, depending on the required current of course. I still hold on to having a separate D.C. power jack, which allows long term operation without the need for being plugged into a USB port.

_________________
Regards, KM
https://github.com/floobydust


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Tue May 18, 2021 8:22 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
BigEd wrote:
> In most cases, the USB port doesn't cope well with the turn on surge, as there can be 3-5 filter capacitors, each rated at 68uF. This results in some current-limiting function of the USB port and the SBC resets twice until the voltage level stabilizes.

Hmm, is there any clever circuit design technique, I wonder, which would allow for enough effective capacitance on a board but somehow not involve such a surge at power-on?

A series inductor could be used to dampen the surge. The downside to doing so is Vcc on the board would (relatively) slowly ramp up. Depending on the design, the MPU might not cleanly come out of reset in such a case.

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Tue May 18, 2021 8:27 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
GARTHWILSON wrote:
...There are plenty of reasons I don't like USB.

The "U" in USB is supposed to mean "universal." Just how "universal" is something that has myriad different and incompatible connectors as part of the standard?

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Tue May 18, 2021 8:37 pm 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
I thought the 'U' stood for 'unimplementable' or 'unacceptable'. Or perhaps 'unorthodox', or 'unstable'.

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Tue May 18, 2021 10:30 pm 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
BigDumbDinosaur wrote:
A series inductor could be used to dampen the surge. The downside to doing so is Vcc on the board would (relatively) slowly ramp up. Depending on the design, the MPU might not cleanly come out of reset in such a case.

My concern about that is that there would be a resonance between the inductor and the bypass capacitors, not just causing an oscillation with every instantaneous increase or decrease in current, but even a hefty overshoot in power-supply voltage.

And yes, there are at least nine kinds of USB connectors, and you can't make your own cables on the workbench. I am not aware of any non-SMT board-mountable USB connectors either. There are of course other problems with USB too, so although USB was convenient for the consumer, it's definitely not for the hobbyist & technician.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Tue May 18, 2021 11:41 pm 
Offline
User avatar

Joined: Thu May 28, 2009 9:46 pm
Posts: 8514
Location: Midwestern USA
enso wrote:
I thought the 'U' stood for 'unimplementable' or 'unacceptable'. Or perhaps 'unorthodox', or 'unstable'.

Jocosity aside, I've long been convinced USB was developed to circumvent the fact that TIA-232, the original "universal" serial interface, was not a proprietary standard. In the realm of electronics, he who owns the standards owns the market for anything built to said standards. USB exactly fits that case, along with SATA, SAS, Firewire, etc. Good luck trying to get an official copy of the applicable standard without handing over a lot of money and signing various legally-binding agreements. I have copies of the official parallel SCSI standards, but got them before INCITS took over SCSI stewardship from the ANSI X3 committee and suddenly demanded one purchase a membership (currently about 1300 USD for individuals and companies with less than $3 million annual revenue) before any document access would be given.

Garth and I have long-advocated for the continued use of TIA-232 (aka RS-232 or EIA-232) for interfacing homebrew computers instead of the opaque USB. High-quality UARTs are readily available and easily interfaced to the 6502 bus, suitable transceivers are readily available for driving the link, and the interface is straightforward to implement using cheap UTP cable and off-the-shelf connectors, e.g., DB-9, 8P8C, some wires twisted together, etc. None of that describes USB.

Another plus is a TIA-232 link running on CAT5 UTP cable with suitable line drivers can be run at high speed over a considerable distance. My company did an installation in the latter 1990s in which we had one link running at 115.2Kbps through some 325 feet (~100 meters) of cable with complete reliability. Compare that to USB's official limit of 15 feet (~5 meters)...

_________________
x86?  We ain't got no x86.  We don't NEED no stinking x86!


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Wed May 19, 2021 1:51 am 
Offline
User avatar

Joined: Sat Sep 29, 2012 10:15 pm
Posts: 904
GARTHWILSON wrote:
...so although USB was convenient for the consumer...

Kind of... I suppose plugging in a USB printer is a no-brainer compared to setting DIP switches on a Grappler card in an Apple ][, but I have a new Brother printer that absolutely refuses to connect as a USB device, while it works over WiFi... The convenience of USB-serial ports (the only way to get a serial port on a modern machine) is often interrupted by the port sporadically teleporting to a different device name, forcing a manual reconfiguration of terminal settings, scripts, and spelunking for USB device ids for init scripts that I'd rather not know about.

I would gladly set a DIP switch instead.

The biggest convenience -- not dealing with device drivers -- is a side effect of the Internet and a cultural shift; little to do with USB (any standardization of identifying hardware would do).

In my largish family android phones are replaced often, and guess what fails most often? Not the battery or display. The USB charging connector gets so loose that cables fall out, or a pin inside breaks. The cables need a monthly replacement. I was dragged away kicking from a flip-phone that never crashed, lasted a week on a charge, had a sturdy barrel power connector, and was replaceable for $5.00 on ebay. Unfortunately the servce charges got so high (equal to 4 smart phones with a Sprint reseller) that I gave up. Progress, right?

BigDumbDinosaur: right on. Not to mention the 65SIB developed here or even plain SPI which accomplish a lot of what USB promises without the awfulness (over shorter distances).

_________________
In theory, there is no difference between theory and practice. In practice, there is. ...Jan van de Snepscheut


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Wed May 19, 2021 2:50 am 
Offline
User avatar

Joined: Fri Aug 30, 2002 1:09 am
Posts: 8546
Location: Southern California
enso wrote:
The biggest convenience -- not dealing with device drivers -- is a side effect of the Internet and a cultural shift; little to do with USB (any standardization of identifying hardware would do).

Good observation.

Quote:
Not to mention the 65SIB developed here or even plain SPI which accomplish a lot of what USB promises without the awfulness (over shorter distances).

The name is short for "6502.org Serial Interface Bus." (It gives credit to this forum, but can be used with other processors just as easily as with the 65xx.) It's designed to be a much more hobbyist-friendly way to hang lots of outboard synchronous-serial devices on a single 65SIB port on the controller, with a very simple method of auto-addressing, and interrupt support, and lots of other attractions. It's mostly SPI but more flexible, and allows (but does not require) added intelligence for auto-configuration, hubs, etc.. It is intentionally very easy to understand, and does not require programmable logic, or anything else that some may shy away from. There's power available on the bus, but it is expected that any device that uses it will use something like a 78L05 regulator to take it down to the voltage that device uses. This avoids the problem of the voltage drop discussed further up in this topic. For those who haven't been here long: You can find the spec at viewtopic.php?t=1064&start=105 . Near the end of that post there's a long list of 65SIB features, design goals, and a few limitations. A few forum members here have adopted and implemented it.

BigDumbDinosaur wrote:
Another plus is a TIA-232 link running on CAT5 UTP cable with suitable line drivers can be run at high speed over a considerable distance. My company did an installation in the latter 1990s in which we had one link running at 115.2Kbps through some 325 feet (~100 meters) of cable with complete reliability. Compare that to USB's official limit of 15 feet (~5 meters)...

For those unfamiliar with RS-422 and -485: They use the same signaling protocol, IOW, can use the same UARTs, but the line drivers and receivers are different, and don't require the higher voltages. RS-422 can do 10Mbps at 40 feet, and RS-485 can do 35Mbps at 33 feet. Both can go at least 90kbps at 3/4 mile.

_________________
http://WilsonMinesCo.com/ lots of 6502 resources
The "second front page" is http://wilsonminesco.com/links.html .
What's an additional VIA among friends, anyhow?


Top
 Profile  
Reply with quote  
 Post subject: Re: Reliability (oops?)
PostPosted: Thu May 27, 2021 12:26 pm 
Offline
User avatar

Joined: Tue Aug 11, 2020 3:45 am
Posts: 311
Location: A magnetic field
Given drogon's recent re-location, it is obvious that drogon has moved further from a power station and is therefore incurring more voltage drop. More seriously, drogon demonstrates that the 5V from USB looks convenient but it should be treated with the same suspicion as a 9V power jack.

I share the general consensus that USB power negotiation is generally mis-guided. In all of my bodging, I've never mixed power and data. I am horrified that a device, colloquially known as a USB condom, acts as a packet filter to allow power negotiation while (hopefully) blocking all other communication. This allows convenient public charging, such as in an airport, to occur without a device sharing its address book, calendar, passwords, crypto wallets and cached files.

In the good old days - when gasoline cost 30 cent per gallon and an efficient vehicle obtained 15 miles per gallon - unregulated 12V was stepped down to 5V with vast inefficiency; typically less than 50%. Furthermore, in the NMOS era, an idle chip consumed a minimum of 20mW and the scale of integration was such that 80 chips or more were common. For example, many of Acorn's designs. That's 5W to do nothing.

I am not impressed with modern design but I see hope of improvement while protocols become less hostile to amateurs - or at least people who have not paid for a proprietary specification.

One of Dave L. Jones' thousands of videos (probably somewhere from 800 to 1100) is an investigation into the root cause of an Apple laptop failure. In a quest to make smaller, lighter devices, Apple used an internal connector which is like a Centronics connector except that it is approximately 2mm thick and the pins are approximately 1mm apart. This is not the cause of failure. The design process within Apple had become stratified to the extent that it was not obvious to any individual that 100V electro-luminescent back-lighting was 1mm from an unbuffered processor signal line. Surprisingly, this meets international safety standards and works in ordinary conditions. Unfortunately, a stray cup of coffee is enough to destroy the processor. Attempt to replace the processor may invoke a processor power regulation flaw which was copied over from the previous design iteration. Specifically, inadvertent solder reflow of the surrounding circuitry may cause an intermittent power problem which looks like the processor was not replaced correctly. Erroneous attempts to make further component substitutions are likely to worsen the situation. It looks like a particularly underhanded example of planned obsolescence but Apple's deficiencies with power supply go back to Apple II where outdated switched mode designs were often copied across design iterations.

We have a situation where V = IR and P = IV = I^2R. Power, P, increases because people want fast charging. Resistance, R, also increases because people buy increasingly shoddy cables on the open market. The only way to avoid the square effect of coulomb heating is to only allow official cables, enforce safety features such as moisture detection, make power negotiation ridiculously complicated and/or increase voltage, V. Unfortunately, parties like Apple have burned their goodwill with leads. For example, does anyone remember Apple's 5*6 laptop SCSI connector or the RCA/phono power connector? It is also less well known that Apple Desktop Bus patents were part of the foundation patent pool for USB implementation. When Apple's 6502 products ceased funding Apple Macintosh development, Apple was a failing company. And then Apple magically bounced back with iMac and top-tier USB support. Forget all of the management drama. Apple made money from every USB device whether or not it worked with Apple products. And that came from a patent which allowed 512 word PIC microcontrollers to send data to a 6502/65816 host over a common bus.

Anyhow, we are likely to see USB power negotiation rise to 50V (the limit established for exposed telco wiring) or 100V (approximate air breakdown voltage for USB C pin spacing). We are also likely to see a corresponding round or two of exploding phones and similar. At 100V, only require 10mA to deliver 1W power and it is too tempting to ignore. I briefly considered the (hopefully) facetious suggestion to interleave pulse charging and Gigabit Ethernet. I thought "Can I get my cell networking to do that? What am I thinking? No, that's a stupid idea." It violates the constraint to separate power and data. Unfortunately, someone, somewhere may not reach the same conclusion.

I am also concerned that protocol checksums are weak or absent - and approximately nothing uses two phase commit. This creates a situation where increasingly complex attempts to stay within safe limits invoke bit error and cause the unsafe conditions which are trivially averted. We will also have the situation where moment-by-moment monitoring will be entirely in software with no hardware interlocks. And said software is not written to any safety standard.

Nokia, another company sustained by patents, commonly implemented a safety feature where absolute humidity and temperature sensor input is used to determine relative humidity. If a limit is exceeded, the radio interface is not powered. This type of safety feature may be introduced to each end of a USB cable; possibly adjacent to registers for active signal dampening. There is also the possibility that larger connectors may allow charging to exceed 1kV.

This is where it converges with data-centers (and hobbyists). To increase energy efficiency, data-centers increasingly use 380VAC to the rack, 12VDC across the board and then local Buck and linear regulation adjacent to each subsystem. With the pre-condition of using 5V signalling as an interchange standard, this gets back to 1970s practice of 12V unregulated power stepped down to 5V where needed. However, it is now possible to do this with 96% efficiency while also inter-operating with 0.95V GPU cores and FPGA, 3.3V OLED, 3.7V exploding lithium batteries, drogon's suggestion of 4.6V undervolted 6502/65816, 5V USB and 12V UART.

So, don't despair. Protocols, such as 65SIB (with unregulated 12V and signalling at 5V) are the vanguard of common sense.

As a workaround to drogon's immediate problem, I recommend a Buck/Boost via 3V or 7V and then to good 5V. I also thank drogon for the cautionary tale that 5V USB is not consistent even across ports of one host.

_________________
Modules | Processors | Boards | Boxes | Beep, Beep! I'm a sheep!


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 15 posts ] 

All times are UTC


Who is online

Users browsing this forum: No registered users and 60 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
cron