Post Reply 
New Project wp34s micro usb flash cable revisited
02-08-2015, 07:01 PM (This post was last modified: 02-09-2015 06:20 PM by matthiaspaul.)
Post: #22
RE: New Project wp34s micro usb flash cable revisited
(02-08-2015 02:04 PM)MarkHaysHarris777 Wrote:  nice to meet you...
Nice to meet you, too.
Quote:I have not had any difficulty using terminal, usually minicom on gnu/linux, but then I configure things as a null modem and disable all the hardware negotiating. I can tell you that the board I'm using is 'flaky,' by that I mean it does not work with MySamba 100%. ... about 80/20. If I retry it will work. I don't know whether its the timing in Marcus' stuff; but I suspect that the unit needs to be in the right state (115200,N,8,1) or it won't work. I open up terminal and make the settings, then close terminal without reset.... seems to be more reliable; but its not 100%.
From your description that problem does not seem to be related, but regarding the right state in general, communication also won't work, if the data connection would attempt to use hardware handshake, a setting which can be overlooked easily when configuring it manually. If the RTS/CTS lines are left floating on the converter side, hardware handshake cannot work, so any communication requesting it will fail. Once these unused signals are shorted, it will work regardless of the hardware handshake setting. I have seen colleagues pulling their hair while unsuccessfully trying to establish a 3-wire serial connection when all they had to do was to disable hardware handshake - therefore, in my own designs, I have come to the habit of always looping back the handshake signals when they are provided but not needed, so it becomes a no-brainer when setting up the software later on.
Quote:I didn't think Harald's board had any advantage (but I was wrong). [...] I realized that the board ALSO has the IR driver circuit on it... solder the IRD directly to his board which has the driver transistor and current limiter.
Hm, judging from the photo of Harald's board in this thread:

http://www.hpmuseum.org/cgi-sys/cgiwrap/...186#223186

he isn't using a driver transistor. The anode of the IR LED is directly connected to a port pin of the ARM CPU, and the cathode is connected to GND via a 390R resistor (R5) in 0805 package.

He's using a SOT-23 dual Schottky diode (D1) in common anode configuration like the BAS40-06 to route the 3.3V from the converter chip to the calculator's VCC input and derive a switching signal for the transistor (T1), which, when a positive voltage level is asserted, opens the connection between the power coming from the combined plus side of the coin cells and the calculator's VCC input, thereby avoiding a reverse current into the non-rechargeable batteries, which would ultimately result in battery leakage. By default, the transistor's control input (gate) is pulled down to GND by a 3.3k resistor (R4).

I don't know if this was discussed in old threads already (if so, I haven't found them), but at first glance, Harald's design might seem to be more complicated than necessary, after all, a common-cathode dual Schottky diode should do as well when combining the 3.3V provided by the converter IC (when bus-powered) and the ca. 3.0V from the built-in batteries.
However, while the voltage drop on the diode is no issue for the USB power path, and, in such a low-power design, the voltage drop can be reduced down to ca. 0.1V to 0.2V for the battery power path as well by choosing a suitable ultra-low-drop Schottky diode, even this low difference is quite a bit in terms of maximum battery utilization - I guess, it would already reduce the time the calculator can run on a single set of batteries by a couple of days. Also, all such ultra-low-drop Schottky diodes typically suffer from a rather significant reverse current up into the low milliampere region, so, to a limited extent, an exhausted battery might still be reserve-powered when USB is plugged in, and, if a dual cathode diode would be used, the battery could be drained out through the converter chip as well. This makes the "ad-hoc" approach of just using diodes to combine the power paths less desirable, and is probably what led him to use a transistor instead.
A bipolar transistor wouldn't make much sense here, though, that's why I assume that Harald is using a FET (I cannot decipher the marking code in the photo - something like "NHW" or "HW", perhaps?), thereby taking advantage of the near-zero voltage drop between source and drain when fully closed, much like in a real switch or "ideal diode".
However, if he's using a FET, the design is missing some ESD protection as one of the FET's pins is directly connected to the batteries' plus pole and will be touched by humans.
In a perfect design, the two coin cells shouldn't be directly connected as well, as this will reduce their combined capacity due to drift currents between the cells if they are not both identical (they never are due to tolerances and discharge history). Ideally, they should be handled as two independent inputs into the circuitry, so R4 and T1 (as well as the missing ESD diode) would have to be doubled for the second battery, very slightly increasing the costs.
Quote:The voltage levels on my board are called 5.0 and 3.3; however, they measure at 5.1v and 3.4v / both depend on the regulators in the PC of course, but the 3.4v on the board is being regulated on-board, and its fairly robust.
I see. While this is still within tolerances, most likely the meter is sligthly off - at least the 3.3V supply is typically matched quite narrowly.

Greetings,

Matthias


--
"Programs are poems for computers."
Find all posts by this user
Quote this message in a reply
Post Reply 


Messages In This Thread
RE: New Project wp34s micro usb flash cable revisited - matthiaspaul - 02-08-2015 07:01 PM



User(s) browsing this thread: 1 Guest(s)