From the literature there:
When switching the input from a ‘0’ to a ‘1’, you will have to account for the time the input takes to rise because of the RC time constant formed by R1, and the input capacitance of the 5V input plus any stray capacitance on the board.
That seems Hin -> Hout, with delay.
The symbol seems a depletion n-channel transistor. Microchip should make clear which one behaves as in the descriptions.
Hin → Lout, with delay.
Here is another explanation for the same circuit:
I think it was an oversight that Microchip did not mke it clear in their DS01146B paper that this 3.3v to 5.0v translator also inverts the signal … 
From the symbol it seemed a depletion mode n-channel fet, but, although they admit positive and negative Vgs, their working is documented for negative ones (0V off, negative voltages on).
That paper is ten years old. Several things can happen:
-The transistor there is a mysterious or ideal component.
-Errata: should say:
When switching the input from a ‘1’ to a ‘0’…
-Let the author of DS01146B, chapter 8, tip #6 explain it, or someone working in Microchip. It is a very big company which recently acquired Atmel.
TI has also a simple Voltage Level Translation Guide.
So let us stay with the simple level translators widely available, cheap and requiring minimal soldering (and no cutting). With dual ones you can feed two strips, with quadruple ones four; imagine cutting and soldering for four strips.
Agreed … 
Well that is strange - when I tried to post my brief (one word) reply, this message popped up:
I wonder why it must be more than 20 characters? 
Wait a minute. On the Pixhawk, both AUX and Main signals come from TXB0108:
( 8-Bit Bidirectional Voltage-Level Translator with Auto-Direction Sensing and
±15-kV ESD Protection)
with separate VCCA (recommended 1.2V to 3.6V) and VCCB (recommended 1.65V to 5.5V), but both are connected to 3V3.
Vohb has minimum VCCB-0.4V, roughly 2.9V (low).
So it seems that if VCCB were connected to J901-VCC (moreless servos/ESC’s external supply) no level translator would be necessary, but this implies a redesign of the PCB.
Output signals would be truly 5V (or external supply). Any drawback?
This is not correct. Someone can use high voltage servos, so if J901-VCC is greater than 6.5V (VCCB maximum rating) U901 and U902 will be blown.
So other 5V internal supply is more appropiate, such as IO-VDD_5V5, VDD_5V_HIPOWER or VDD_5V_PERIPH.
I am trying to set up a WS2812 led to display the standard NTF notifications, but I get no output on a CubeBlack. I have set the following parameters:
NTF_LED_TYPES to 255
SERVO10_FUNCTION to 120
BRD_PWM_COUNT is 4
NTF_LED_OVERRIDE is 0
Is there anything else I have to set?
what other stuff haw you got setup on the servo outputs?, it could be a grouping issue. You also have to power the LED’s, ie plugging only some NeoPixel’s in wont work you need a bec also.
Nothing else is connected. For good measure I moved it to Servo14 to avoid potential grouping issues. I set NTF_LED_TYPES to 455 and now it kinda works, but displays a strange behavior:
The signal is level shifted, but insted I also tried reducing the supply voltage to the LEDs to 3.3V. Same issue.
1 Like
looks like its working OK to me, flashing yellow is expected on boot.
The flashing is irregular and only one LED is lit.
I am using WS2812 (so no B) LEDs. Could this be the issue?
Only one LED is expected, if you want more you can flash latest and use the new parameter (warning this not stable firmware might be other bugs ect). Irregular could be something to do with the level shifting, it looks like its missing some commands. You could try directly from the servo output.
Only one LED is controlled, got it. Regarding the irregularity: it makes no differene if I connect it directly, level shift the signal, or supply the LED with 3.3V. The irregular flashing/missed commands is always the same. Chnaging to a different Servo output also makes no difference.
I just tested it on a Pixhawk 4 and the LED blinks as expected.
No luck with the CubeBlack.
edit. Further investigation:
I just tried resetting the parameters to default and only changing the parameters NTF_LED_TYPES, SERVO14_FUNCTION and BRD_PWM_COUNT and like this it works as expected. After reapplying my parameters, the irregularity/missed commands is back. Maybe someone could take a look at them: NeopixelIssue.param (18.1 KB)
I am getting similar behaviour as reported by @Hoehenarbeit on a Pixhawk 2.4.8. I am using level shifting and a separate 5.1 volt supply to the WS2812’s.
For example, when the internal LED in the Pixhawk is flashing yellow, the WS2812 will flash yellow, but irregularly. It will not flash in synch with the main LED, but misses some flashes as if it sometimes doesn’t get the correct data.
I haven’t finished investigating if it is a hardware issue with the level shifting, the particular WS2812 or the 5.1 v supply, but given @Hoehenarbeit’s similar report, it sounds like a firmware issue?
Cant see anything obvious in the params, you do also have SERVO10_FUNCTION set to 120 can you try with that at zero (or test with defualts and set it to 120).
Other than that you could try on the latest firmware, it could be a bug that has already been fixed but not made it to the release, dont fly unless your happy using less tested firmware, might be other bugs ect.
Could just be there is more going on so the timing gets abit loose.You also try turning changing a few params at a time and see if you can narrow it down abit. Maybe try servo functions and serial ports first.
I am using the latest beta of both AP and MP and I cannot find this new parameter, mainly because I am not sure where to look - could you please tell me what it is labelled?
BTW, I have tried all different hardware (LEDs, level shifter, flight controller) and installed the latest AP beta and I still get the erratic flashing, so it does look like it is a software timing issue … 
I even have the recommended 330 ohm resistor in the date line to the WS2812B and a 2200uF capactor across the 5v at the LEDs, but still no improvement.
It would be a pity if we can’t get this to work reliably as it would be very useful to have some bright LEDs at the rear of the drone to display its status from a distance.
latest latest not latest beta, might be bugs, not stable firmware ect ect
OK, I have installed AP ver 4.0.3-dev for a Pixhawk1 from here and I can now find the parameter NTF_NEO_LEN and have set it to 12 (for a ring of 12 WS2812B LEDs).
However, the problem of the NeoPixels not flashing in synch with the internal LED remains.
I did some further testing and the problem seems to be related to serial communication. If I disable Serial1, the LEDs blink normally. If I enable it, but reduce the SR1 rates I observe much less irregularity/missed commands.
Is it possible, that the CPU gets overloaded by the Neopixel feature, or is this only a software issue?