Just received my the Mezzanine Sensors to be used on my DragonBoard.
My board is defined as Level C (stamped on the board) and found the documentation as such (that the only one) I mean Board Level C.
Layout and Schematics are level C.
Tried to lit the only 2 user LED on the board using Android. User LED are named 96BOARDS GPIO LED. Sounded a good idea.
LED defined as D9 and D10 on the schematics and layout.
Spend a few hours to find out that these LED are NOT on the board at all. Not as component missing. But Not present at all, no track no solder leads.
What is going ON? Where are those LED gone and why the produced does not update the documentation.
What else is not matching the schematics? We should avoid to waist time looking for such problems.
Quite disappointed for the quality of the product.
Jean-Marc
Hi @jmjobin,
The LEDs for GPIO_A and GPIO_B were removed at the last minutes while debugging since the LEDs were drawing too much current.
The R13, R14, D9 and D10 are the components missing on the Sensor Board Rev C compare to the schematic.
It was really unfortunate decision.
We might need to make another reversion?
Akira, thank you for the answer.
It would be nice if someone would update the schematics and layout without delay.
By the way, for the “LED drawing too much current”! Sorry for my following comment but:
1k with 5 vdc less diode level is about 3 volts -> is 3 mA per LED. Honestly this is not too much, what happen for the other numerous peripherals on the board once connected? Do they draw less than 3 mA?
I will be on Openhours in a short time and we may have a talk about this? Till soon 
Hi @jmjobin,
Yes the capacity of the power itself is fine.
The issue was the TXB0108PW which used for the logic level shifter for the GPIO_A and B became fragile.
Would like to revise it in the future.
Akira I thank you for your answers.
For the “revising” I am not sure to understand what you mean
Have a nice day.
Sure! and what do you want me to do? Suggestions? Testing? I will be happy to help.
Hi @jmjobin,
We need your help.
This is the github of the kicad data of the sensor board.
It would be great if you update the schematics and replace the TXB0108PW with FXMA108 (or any equivalent logic level shifter) and ask us the pull request.
Then it will start us working on Rev D.
OK! Still do not understand why!!! according to me the Output Current Sink MAX is +/-50mA for both of them. I probably miss something!?
I will do it but I do not have a CAD and will need to install a CAD.
I think you are using Eagle. Will need to install it and learn how to use it. Give me some time
I also have to work 
Sorry, KiCad is the one, it is new for me. I am installing it.
OK done!
- Create the FXMA108BQX in the sensors library
- Swapped the TXB0108 with the FMA108 in the sensors.sch accordingly (signal/pin swap etc…)
I will need some directive on how to supply you this changes, pls contact me by email.
Robert Wolff has my mail address in case.
Have a nice WE
jean-marc
Hi @jean-marc,
Thank you for your fast and great help!
My linaro email address is
akira dot tsukamoto at linaro dot org.
Sending me the kicad data file is fine.
Sorry Email error, I cannot reach this address 
I’m inclined to repeat something Jean-Marc said earlier about updating the schematics and layout at https://github.com/96boards/96boards-sensors .
Schematic diagrams that don’t match the actual board is really disconcerting since they undermine confidence in other areas. It would be great if we could update the schematics to match the shipping boards before we start thinking about merging in any rev D development!
Before you guys rush another rev of the sensor mezzanine board, you really need to get to grips with the fundamental inadequacies of the auto-bidirectional level-shifter chips as interfaces to random external electronics over random cables.
Chips like the TXB0108 or FXMA108 are intended for interfacing between two well-defined logic domains (of differing voltage swings) communicating over short distances on a PCB with traces designed for high-speed signals, properly terminated, into high DC input impedance receivers.
They are not intended for GPIOs. They have neither substantial DC output current as outputs, nor high input impedance as inputs, and a high tendency to oscillate.
The fundamental problem is that their direction-switching feature depends on the ability of a connected chip to override the level-shifter’s output sufficiently to tell the level shifter to change direction. This means that the level shifter output has a relatively weak output current (ie: easily over-ridden, and thus not adequate for driving any significant load, such as even many Grove devices. And that is the root of the LED problem on earlier revs.) So, they provide poor mezzanine outputs.
Further, because they require significant current to switch and maintain direction (up to 750uA), that means that as mezzanine inputs they are poor too.
Worse, this problem is compounded by a “special feature” on these bidir drivers: Such a low output drive current working into bus capacitance would result in slow lo-hi or hi-lo transitions. To mitigate, when transitioning, these drivers emit a brief high-current pulse in the appropriate direction. That’s fine into a controlled PCB run with termination. Into random wiring, it will create oscillations which not only bounce the signal, but those bounces cause the direction-detect to think it should reverse direction. Result: the driver has a high tendency to oscillate at some high frequency (10s of MHz).
FWIW, the FXMA108 you’re talking about replacing the TXB0108 with is no different. Sure (@jean-marc) the data sheet says IOH/IOL -/+ 50mA. However, that’s not the spec for the driver I/Os. The relevant spec is IIODH and IIODL, up to 750uA. In other words, the actual DC output drive capability is less than that. More detail in the Fairchild FXMA108 datasheet in the section “Lower Power Consumption”.
In short, mezzanine I/Os implemented with auto-bidirectional bus level shifter do not have satisfactory DC behavior, and in the role in the Sensor board, are highly likely to generate high-frequency transient or ongoing oscillations, leading to very puzzling symptoms. Instead, hardware experimenters need inputs and outputs that have zero hassle and no surprise instability, while in any particular application, experimenters almost never need bidirectionality. To actually use the existing Sensor board realistically requires the user to supply an additional layer of hardware I/O buffers external to the mezzanine, rather defeating the merit of the Sensor board in the first place.
A useful mezzanine card would break out completely separate hi-Z inputs and hi-current outputs, using unidirectional level-shifters, either to separate connector pins, or jumper-selected.
(And FWIW, I concur with recent discussions on OpenHours: Don’t need both 3.3 and 5V I/Os simultaneously, make that a jumper to control all I/Os at once). And DO need a way to connect to and program the onboard Arduino directly (not just through the low-speed connector from the DB).
I hope this prompts some discussion and redesign, because without it, the DB410c is rather stuck in a limbo of hocus pocus hearsay when it comes to end users trying to hook it up to external things in the relatively carefree way they may be accustomed to on Arduino or RPi.
As a further note: I think it would not be going too far to say that as currently designed, these Sensor boards are not fit for purpose (and it would be understandable if existing customers requested working replacements).
As a bare minimum, given that the Sensor board has Grove connectors, we would expect that the board would be able to operate Grove modules without issues. Yet there are quite a number of Grove output modules that require only modest drive current, which normal 3.3 or 5V GPIOs could supply with no problem, but which the Sensor board’s level-shifters cannot. There are also Grove input modules which expect to be driving a high-impedance input, but will not work into the Sensor board inputs.
And if there are problems working with just Grove modules for which the Sensor board is ostensibly designed, then one can expect that end-users will have plenty of trouble trying to treat the level-shifter I/Os as “general purpose”.
I should also mention that this is not the only GPIO level-shifter adapter board that has this kind of problem due to misunderstanding auto-bidirectional level shifters. Sparkfun’s level-shifter/breakout board for Intel Edison https://www.sparkfun.com/products/13038 uses the same level-shifter chip and has all the same problems. I’ve personally hooked that up to a scope and watched its unusably low output drive current and almost unstoppable oscillation. (“Solution”: we removed the TXB0108, soldered jumpers across the pads, and just used the board as a mechanical breakout to access the unmolested 1.8V signals.)
Again, if a revision is in the works, I really hope that it’s an occasion to stop using this unfortunate design, and build something that works trouble-free (which pretty much means unidirectional level-shifters.)
Excellent comments, I worked on this more deeply looking better on datasheet and testing.
I agree, the result is as you guys comments, the current sink on single pins are negligible and cannot drive anything.
I arrive to the conclusion that an impedance of about 100k refer to GND is the maximum load to keep the level without oscillation risk of locking the signal. (I could lock the signal with higher load)
A simple solution to drive a current would be to add a buffer if the component need to be output.
We could drive any load component with a simple NPN transistor or a FET without a complete redesign.
This at least for the 2 missing GPIO with LED.
For the input I did not test but I think the design as is should be OK.
Anyway this is at the end is just a level shifter, the user could (should) also care about the load drive.
The board is also very small and not too much space to add stuff.
And looking at it it is not as bad design as mentioned
I was able to program the Arduino error free (which is not always the case on other suppliers) and the console works well on the micro USB.
Hi jean-marc and all,
You are of course welcome to do what you like with the Sensors board. However, if you continue with the auto-bidirectional level-shifters, and expect you or users to patch problems ad hoc by some combination of external transistors or buffers, then this mezzanine board, which is offered as THE solution for GPIOs, will continue to undermine adoption of the 96Board ecosystem. Not the least problem being that just the wiring to those external buffers will prompt oscillation.
Further, you’ll still have to explain why basic Grove modules don’t work, such as input modules like Button (http://wiki.seeedstudio.com/wiki/Grove_-Button) and Switch (http://wiki.seeedstudio.com/wiki/Grove-Switch(P)) or Water Sensor (http://wiki.seeedstudio.com/wiki/Grove-Water_Sensor) and output modules like Relay (http://wiki.seeedstudio.com/wiki/Grove-_Relay). More vexing, , even some other ones that do sometimes work will be marginal and flaky.
Clearly the Grove connectors convey that this board is intended to produce or consume signals used by common rudimentary peripheral components. Like you can connect straight to Arduino and other 3.3 and 5V microcontrollers. Yet it doesn’t.
Sure, the I2C and Arduino sections of the board have some merit. But as a way to hook up the Dragonboard GPIOs to commonplace external components, the absolute simplest scenario, with which users may test their their first software I/O baby steps, this board actually makes life more difficult than a simple connector breakout with no level shifting or buffering. (Especially now that it’s minus LEDs.)
Even just consider how you’d drive an NPN transistor. How much base current are you going to get from one of those level shifters? Barely enough to allow the transistor collector to reliably sink even 10mA. Contrast that to driving the same transistor directly from the Dragonboard 1.8V I/Os. You could easily get 5-10mA into the base (so say 300-1000mA at the collector if you wanted), and zero risk of oscillation.
And not that everything RPi is wonderful, but at least their popular GPIO adapter board ‘Gertboard’ (https://www.element14.com/community/docs/DOC-69381/l/gertboard-for-raspberry-pi) solves signal buffering sensibly, with separate unidirectional input and output buffers.
Sorry to press on this point so firmly, I know everybody here is earnest and wanting to make a positive contribution. But it’s just too predictable the befuddlement and frustration this board will cause, and the waste of your time and effort, if the present auto-bidirectional design continues.
Gwidman,
I did not test any accessories yet, but, I have nothing to add more about your comments beside that is rather bad if they do not function.
The transistor solution just work fine for the LED. I tested this on the 3.3 VDC, but you are right in that point we could just drive it from the 1.8 vdc why bother a level shifter.
Then in that point I hope the people who made the board will think on a better solution and get inspire of your (our) comments.
They probably think about a new design? Akiri should probably take position on these comments soon.
Anyway I think you get the point and I fully agree, plus the board costs me $55.- with shipping
