Simplify circuit

[Dakkaron]

This project is amazing! Great work so far!

I think the circuit can be simplified quite a bit though, by leavin out the LMH1980. It is the most expensive part in the design and it's work could be easily done by the ATTiny.

Just replace the LMH1980 with a clamping circuit and use the Analog Comparator included in the ATTiny together with a simple voltage divider to trigger an interrupt each time the clamped video signal dips unter 100mV. This then is the line sync signal. If the line sync signal happens at double speed a few times directly after another, that's the frame sync. On the software side that should not be much of a change.

A similar thing has been done here: https://www.rcgroups.com/forums/showthread.php?1473207-Diy-osd-%28Arduino-and-opensource%29

[nppc]

Thank you. Yes, mine first prototype version was planned with discrete components for video sync detection. But it comes in bigger size, than LMH solution. If there will be interest, why not to make bigger, but cheaper version?

[Dakkaron]

Is it really bigger? I just did a quick comparison in components. If you remove the LMH and its supporting components you loose 3 capacitors, 1 resistor and the LMH, but you need to put 1 capacitor, 3 resistors and 2 diodes. As far as I know, all these discrete components are aboutt the same size, so in the end you trade the LMH against two discrete components.

I am by far no expert in making little SMD boards, so I could be completely wrong. But if you use the built-in comparator in the ATTiny, this should work out to be smaller.

[nppc]

Can you draw something? I have not much time at the moment. If you prepare schematic, I can make PCB. If you like, you can adjust firmware too. :)

[Dakkaron]

I can try to do something in Kicad (I have never worked with it before, but I'd like to give it a try). If I can't get it to work, I'll send you a schematic.

I have done quite a bit with ATMegas, but only in C. I will have a look what I can do with the assembler code. I sadly don't have much possibility to test this all in hardware at the moment, because I am not near my hardware stash and won't be for a while... I hope, my schematic will make sense...

[nppc]

Thanks! Schematic and some C code would be good. Then I can find time to make a draft of the new version.

[brucesdad13]

Excited to see what you come up with! 👍

[Dakkaron]

I currently don't have access to my hardware and testing stuff, but according to simulation, this here should do the job:

VIN is the video signal, V1 is the battery voltage (I simulated it with 3.3V and 5V and both seem to work fine, so I guess, there should be no problem with 1s batteries), AIN0 is pin 5 on the ATTiny13A and AIN1 is pin 6.

In the original circuit, R3 and R4 are realized with a potentiometer so the user can find the optimum values for the reference voltage on AIN0, but I think this can be hard-wired. According to the simulations I have done, these values should be ok, but it might be good to check that on a breadboard with a potentiometer first.

I will post more once I get the time to build something in Kicad. I hope I find the time soon. Otherwise, if anyone else who actually knows what they are doing, unlike me, has some time to build that in Kicad, be my guest ;)

Edit: I needed one more resistor than I originally calculated, so now this solution would replace the LMH by three additional components.

[nppc]

Dakkaron! Thank you! Looks very promising! Let me find the time to make a PCB... Maybe today... :)

[nppc]

Full schematic - draft for V2 :)

[Dakkaron]

Thanks for integrating that! Looks really good! I wonder if maybe there should be a resistor between C2 and MISO/PB1. Or do you think the capacitor there is good enough to isolate MISO from VIDEO?

I have not been able to try this in hardware, so maybe it would be good to test this in hardware before integrating this. Especially the values for R7 and R8 should be verified in hardware, but if they are wrong changing the resistors out should be easy to do.

I am really looking forward to this! Thanks for the great work!

[nppc]

I think AIN1 (PB1) don't need resistor. It is just an input to the MCU. I'm just curious, do we really need 100 Ohm for R6 and R5? Looks they generating a lot of current? Maybe 10K better?

[Dakkaron]

@Resistor values: you are right, that's a mistake of mine. R6 should be 10K and R5 should be 100K.

@PB1: I thought, that maybe the resistor would be necessary so that the pin would still work as MISO for programming purposes, so that In Circuit Programming works. In your original schematic at https://github.com/nppc/B-uOSD/blob/master/KiCad/Schematic.pdf you secured each of the programming pins with a 120 Ohm resistor. I thought, that was for that purpose, so that the ATTiny / the programmer can drive the pins much stronger than the video signal can.

[Dakkaron]

I did some more simulations and the values I found to work best with R6 being 10k and R5 being 100k are R7 as 60k and R3 as 40k. I simulated that with a VCC of 3-10V and everything seems to be stable. This way, power consumption should be quite minimal.

It takes a few cycles for the clamping mechanism to work, but the ATTiny-pins allow for a negative current of up to 1mA, so that should not be a problem. That only means that the OSD should wait for a few ms before engaging the interrupt.

I fear I am quite inexperienced with putting together schematics, so please forgive my mistakes and don't totally trust my results ;)

[nppc]

Ok! Thank you for the help! And I have good news :) As you said at the beginning... I tried to put all higher components to one side, and resistors and 2 caps (low profile) on another... If we look carefully, maybe both caps can be moved to the upper side.

[Dakkaron]

This looks just cool! Thank you for your work!

[nppc]

All tall components on one side. Now the pcb will fit between the PCBs of AIO FPV camera! :)

[Dakkaron]

That's crazy! Amazing work! Thank you!

[Dakkaron]

On the software side, what needs to be done is first, replace EXT_INT0 with ANA_COMP (this is all that is needed for horizontal sync). Vertical sync is a bit more complicated, I am not sure, what the best way to implement that is. I'll just propose one possible solution.

V-Sync is basically a H-Sync at double the frequency. A regular H-Sync happens every 63.5us for NTSC and every 64us for PAL. So if a Sync happen quicker than after 50us it must be a V-Sync.

So first you need a global flag bit, I'll call it is_h_sync and a timer that triggers after about 50us. Whenever a sync happens, check if is_h_sync is set. If it is, treat the following sync as a H-Sync else as a V-Sync. Now unset the flag (set it to false) and reset the timer's counter register, so that it starts from the beginning. If the timer interrupt triggers, set is_h_sync to true.

This is not perfectly accurate, it will always lag one line behind, but for this application that should not matter. Just don't draw to the first and last lines.

The 50us don't need to be exact at all. It just meeds to be more than 35us and less than 60us.

[nppc]

Ok, sounds a good plan. Will later look to the code, when will have a time...

[nppc]

Schematic can be finalized I think. Maybe I can send the board to OSHPark, to have a prototype for debugging the code...

[nppc]

Link to OSHPark PCB: https://oshpark.com/shared_projects/5FUoUMnV

[Dakkaron]

This looks just cool! Thank you for your work! I'll probably order one of the prototype boards aswell.

[Dakkaron]

Just wondering, is there a reason why you are using an ATTiny13a and not e.g. an ATTiny84a? The 84a does not come in the MLF-10 package, but in the MLF-20 package, which has the same size but has pins on all four sides, not only on two sides. Soldering should not be much harder since the pin spacing is almost the sale (0.45mm instead of 0.50mm). Energy consumption is about the same and it is not much more expensve (still below $1 on Mouser). But you gain 6 pins, have 8kb ROM instead of only one and a whopping 512 bytes of RAM instead of only 64 bytes.

With the additional pins you can have the programming pins on dedicated pins which means you don't need R1 and R9 anymore.

And the additional RAM and ROM should allow for more advanced features like reading telemetry from a FC or fonts in multiple sizes.

According to the information I found, the architecture of both chips should be the same so you should be able to use the same software you use now, only needing to change pin assignments.

[nppc]

Hi Dakkaron! Yes, there was a reason. Attiny13a package is 2.9x2.9mm is size, where Attiny85 has a size of 4x4mm. As the project was initially planned as a simple micro OSD, the size of the mcu was more important than a size of a flash.

BTW I had a plan to make bigger pcb with Attiny85 and 20mhz oscillator, but currently I have no time to work on it.

[nppc]

BTW useful pin count is the same for attiny13 and attiny85

[MicroMontis]

So we can just swap Attiny13 with Attiny85? I would stick with Attiny85... just in case we will need more program space :)

[nppc]

Yes, but need bigger pcb, because footprint of attiny85 is 25% bigger than attiny13.

[Dakkaron]

I am sorry, I was talking about the ATTiny84a, not the ATTiny85. The 20M2 package is 3x3x0.85mm, while the ATTiny13a is 3x3x0.9mm (all the nominal values according to datasheet).

Also it adds more usable pins:

[nppc]

Ah, ok! I'm overlooked this. I thought about attiny85, but you wrote attiny84A :) Yes, why not to replace attiny13a with attiny84a... I think this is very good option!

But we need carefully to think, what we do with this. For example,

• I would like to run it with external oscillator, and if possible at 20mhz (gives better stability). Only questionable, how it will run on 1S at 20mhz?
• Then maybe we can implement some sort of serial communication to change settings, and get data from FC. (maybe easiest way to parse MSP?).
• With this chip it is really possible to make small FC with integrated uOSD...

But I have no time for everything :(

[Dakkaron]

• I would not recommend running 1S @ 20mhz. 1S can easily go down to voltages as low as 3V with full throttle. The maximum safe operating frequency for 3V is around 11mhz. According to the datasheet 20mhz requires at least 4.5V. So for that we'd need a voltage booster. The problem is, voltage boosters for 5V are quite hard to come by and usually comparatively bulky (at least from my experience, I'd like for someone to prove me wrong ;) ).

• Parsing MSP should be rather straight-forward if there is more space on the device. I found an Arduino-MSP-parser here: https://github.com/fdivitto/MSP . Looks rather short and simple, so it should not be too hard to implement something like that into B-uOSD.

I'd like to contribute code once my hardware arrives. But I can't make KiCad schematics, since I have no experience in that.

By the way: What is the point of C1? It wasn't in the previous designs. I am asking because my favourite provider of hardware parts does not have any affordable 10uf capacitors and I am wondering if I can just leave it off ;)

[nppc]

Yes, 20mhz kinda Scarry. But 16 I'd like to try. Atmega runs 16 on 3.3 with no problem.

I thing C1 should be there. Bigger is better, but if you have something smaller, it will work too. It is for stabilizing the voltage on MCU. We have analog circuity there, so decoupling is essential.

[nppc]

To implement serial protocol is quite tricky. We have not much power for that. I think we can't use any interrupts while drawing OSD, otherwise symbols will be jittery. So, we can parse serial only within very limited timeframe. Don't yet know is this possible at all or not?

Of course, we can use serial only for configuring, so need to evaluate it.

[Dakkaron]

The ATTiny84a has one USI interface. That's a generalised form of a hardware-accelerated serial interface. This reduces the overhead of serial communication by quite a bit as you only have to poll once 8 bit have been sent. PAL has fewer lines per second than NTSC, so if we want to read one byte per line max, then we can read 15625 bytes per second. That means we could read up to a baud rate of 125000. MSP seems to be running with a baud rate of 115200, so we should be just about fine.

[nppc]

The implementation of UART with USI interface needs quite an amount of CPU time (see AVR307 app note). First, we need pin change interrupt to detect incomming data. Then start a timer to get timing for USI, and update timer every received bit. So, to do it while drawing the text is not possible I think. More over, if I remember right, then MSP protocol requires first to request data, so we need to send data first. Then we don't know exactly, when data will start to come.

So, maybe it will possible to send/receive data, while we not drawing anything.

Please correct me of I'm wrong somewhere...

[Dakkaron]

From what I understand of AVR307 the biggest problem with UART over USI is that UART packages can bei 7 to 11 bit long, while USI only has the infrastructure for 8 bit packages, which then requires the CPU to do a lot of work to work around this limitation.

I have read somewhere that MSP can also be sent over I2C/TWI, which is a lot easier to implement on USI because it is 8-bit-aligned, same as MSP. I2C over USI is detailed in AVR312, but there they use an interrupt to read the packages. As an interrupt is not feasable in this project, there is a way to do this with polling. If the interrupt is disabled, the USIOIF bit in the USISR register indicates that 8 bits have been read and the result has been copied from USIDR to USIBR. Using the USI Buffer Register instead of the USI Data Register to read data means that there it is not necessary to read the data before the next bit arrives, but before the next byte arrives. At a clock speed of 115200 this happens at a maximum of 11400 times per second. We have 15625 lines per second in PAL and a slight bit more in NTSC, so that should work out.

As for writing, I imagine we are in control of when we write, so we could just do that during field sync since we don't have to do anything else there.

If that does not work out, we could just dedicate one field per second for reading and writing. Since most FPV receivers have do do deinterlacing anyways that wouldn't even cause the characters to fully disappear during that frame, but only every second line.

In any event I think the ATTiny84a would be a good choice since it does not cost much more and would add a lot of flexibility, no mattter what will be done with that flexibility afterwards.

[MicroMontis]

I think we should first get a prototype running, just to justify we can do OSD without video sync chip.

[Dakkaron]

I'm just thinking, the ATTiny13a is currently alsmost at its ROM limit with the current state of things. Tha ATTiny84a would make it easier to integrate the additional code necessary for integrating video sync.

[nppc]

Yes, we can test the "video sync less" design with attiny13a because PCB is already on its way from OSHPark, and then we can move to attiny84a as a next step.

@Dakkaron If you like, feel free to start new issue for attiny84a and lets look closer to it after attiny13a version is working. What do you think?

[Dakkaron]

Sounds good. I just feared that the "video sync less" design might not fit onto the attiny13a's ROM. But if you think this works this sounds like a good plan. Migrating from ATTiny13a to ATTiny84a should not be too much work after that (at least in theory).

[nppc]

Space currently should not be a problem. with LMH I was at 75% of Flash, so, 25% is quite a big amount in assembler :)

[MicroMontis]

OMG. I forgot, that it is written in ASM. Respect.

[Dakkaron]

Oh, that's good! I thought I read somewhere in the commits that it was at +90%.

[vidzo]

I have recently found this great little project and have ordered a few V2 boards. I now that nppc is a bit busy with other projects but was hoping there had been some progress with the code? @Dakkaron I'm more than happy to help with testing once I receive and make the boards. I know very little code though...

[Dakkaron]

@vidzo Thanks for the interest! I should really build my boards as well. I have them lying around since a few months. From what I understand, there is really not much left to do. The code should be basically working. The main problem is figuring out which resistor will work for the analog comparator.

[vidzo]

It's a great little project, how could I could not be interested?! I'm more than happy to offer some testing time with various resistor values. I'm going to order some resistor kits in the next few days along with the MCU. Hopefully Oshpark boards come in the next few weeks too

[erneut]

@Dakkaron Hello. Can you please tell me the way you've tested circuit you attached here? I'm trying to understand the way this circuit works but I have no idea how to simulate input signal :). It looks like you used CircuitLab. Did you use "Behavioral voltage source"? If you did what kind of expression did you use? Thank you

[vidzo]

Hey nppc, have you managed to write up a BOM yet?

[nppc]

Sorry, I forgot about it... Thank you for the reminder... Will do it as soon as I can... :) Pavel

вс, 28 окт. 2018 г. в 10:44, vidzo notifications@github.com:

Hey nppc, have you managed to write up a BOM yet?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/nppc/B-uOSD/issues/13#issuecomment-433690335, or mute the thread https://github.com/notifications/unsubscribe-auth/AKaaVcc0m7946KR6CmUJ1TP_LibiVQJxks5upXx7gaJpZM4Qqtpm .

[Dakkaron]

@erneut Sorry for the late answer. I used CircuitLab and I tested it only using sine wave inputs. I didn't come up with the circuit myself, I just copied and modified it from here: https://www.rcgroups.com/forums/showthread.php?1473207-Diy-osd-%28Arduino-and-opensource%29

The main difference between the original circuit and this one, is that the poti was changed to a fixed resistor, since a potentiometer would make the module too large. But maybe a tiny trimmer potentiometer lieing flat on the back of the module might work. They are still way cheaper than an LMH1980. But it would be better if it could be done without one.

[nppc]

BTW: For testing purposes you can omit R8 and use external potentiometer connected to the MOSI pin of the board and to the ground. After finding working value you can solder it in place of R8...