VGA from P2 silicon

124»

Comments

  • You need a good USB cable because any voltage drops result in high current draw from the SMPS and high current draw results in higher voltage drop! Although I use a microUSB for my serial cable, I also use a heavy USB A to USB A which I plug into the USB A on my matrix board to give a nice solid 5V. I find that USB ports have no trouble supplying the extra current, but the cables have to be up to it.

    Exactly right. I have modified a prop plug to have a flying +5v lead, like in this photo for powering the P2D2

    Picking up +5v from the top of the leds seems the easiest access point, as the main +5v cap has the +5v end close to the qfn ftdi ic.

    I have a ~3m usb cable for when its in the dry ice esky, but this only works sometimes, and for proper testing I have to run lab supply lines into the box, the 3m USB cable isn't good enough even though the prop is only taking about 120mA on the +5v rail.

    The shorter, ~60cm white cable always works, no matter what frequency/power draw. Well at least to 320 MHz anyway.
    I once ordered a box load of micro USB cables from eBay only to find out that they were essentially useless since they use signal wire for the power and ground, and signal wire here means a very thin strip of foil wrapped around a thread. Since none of them advertise the cable resistance I found you need to order tablet charger cables instead. But the longer the cable, the greater the voltage drop, the greater the current!

    My favorite is a particular ebay/aliexpress VGA /HDMI converter that comes with its own USB mini B lead. That lead it comes with doesn't have enough copper to power the converter. It works fine with a decent usb mini lead.

    Of course it all just seems dead the purchaser (they wouldn't realize its the usb cable). They must get a lot of returns. Actually their competitors probably just get extra business.

  • oops photo attachment... see where the +5v gets tapped off the top of both leds
    2304 x 1728 - 869K
  • cgraceycgracey Posts: 10,989
    edited 2018-11-16 - 00:33:29
    Bit 2 of the HUBSET value controls the loading caps when the crystal oscillator is enabled. 0/1 = 15pF/30pF caps on each XI and XO. I think adding more pF may make it more stable. Try bit 2 = 1.
  • cgracey wrote: »
    I'm thinking about how the Goertzel can be used to resolve time-of-flight for signals. Goertzel, fast low-Z DACs, oversampling, and CORDIC, all together, should make really interesting measurements possible. It may be possible to achieve micrometer-scale resolution for light and electrical phenomena.

    Speaking of time of flight, I wonder if P2 could be used here, instead of the PPI of the Nordic nRF52 (although that's only a $5 chip anyway): https://hackaday.io/project/160182-hivetracker
  • jmgjmg Posts: 13,355
    cgracey wrote: »
    Bit 2 of the HUBSET value controls the loading caps when the crystal oscillator is enabled. 0/1 = 15pF/30pF caps on each XI and XO. I think adding more pF may make it more stable. Try bit 2 = 1.

    The code in #1 seems to use CC=11 which is 30pF/30pF.
    I wonder what the crystal is, and if a change in Xtal/MHz affects the tests ? What is the Xtal Osc feedback resistor ?

    I have seen careful Xtal specs, but usually that's around higher MHz, and needing lower ESR to start correctly.
    Higher MHz can also need lower Cap specs, as the load-caps drop the available gain -it may be P2 needs 15pF for > 20MHz and 30pF for < 10MHz
    Max Xtal MHz has not been defined yet ?
    SiLabs specify to 48MHz, but to get to there, they do tighten up ESR & C
    More common is 25MHz or similar as a Xtal spec. IIRC Atmel had issues with 20MHz xtals

    Most Xtal issues I've seen are around starting, as the Hi Q and stored energy actually make a running xtal hard to disrupt.
    ie a whole-hand-grab can stop a oscillator, but here that usually shifts the bias via the high feedback resistors.

    It seems strange that level of Osc C could match these unusual test results :
    ozpropdev wrote: »
    With my board running Cluso's code image is fine.
    The 'shiver' appears if I place a finger on the chip near the XO/Xi corner.
    The closer I get to the oscillator corner the worse it gets eventually losing video all together.

    Another test point would be to remove the xtal, and swap in a CMOS-out oscillator, and check again.
    It's also useful to test a clipped Sine oscillator, via an AC coupling cap to XI (Caps set for 0pF).
    If the issue persists, it then sounds like a floating node in the VCO/PLL, which is a less desirable fault.

    other possibles ? - How good is this manual packaging ? Is it maybe a worse/degrading insulator than a real package ?
  • jmgjmg Posts: 13,355
    Cluso99 wrote: »
    .... I noticed the P2 gets hot w/o a fan and does start to shiver. A finger on the P2 fixes short term. I have posted this code below.

    Does your shiver symptoms, match these reported by ozpropdev - it seems not quite the same ?
    In your case a finger fixed it, in his case, a finger lost video ?
    ozpropdev wrote: »
    With my board running Cluso's code image is fine.
    The 'shiver' appears if I place a finger on the chip near the XO/Xi corber.
    The closer I get to the oscillator corner the worse it gets eventually losing video all together.

  • I didn't have time to any detailed tests.
    There are lots of things that could be causing this.

    BTW I have a xtal osc 12MHz on my P2D2. I think Peter used the same osc on all boards.

    I was just amazed to see a pic at 1080p.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 13,355
    Cluso99 wrote: »
    BTW I have a xtal osc 12MHz on my P2D2. I think Peter used the same osc on all boards.

    Do you mean 12MHz crystal ? or do you mean an external Oscillator module, xtal based, with CMOS logic out ?

  • Peter said it was a 3V3 oscillator.
    My Prop boards: P8XBlade2, RamBlade, CpuBlade, TriBlade
    Prop OS (also see Sphinx, PropDos, PropCmd, Spinix)
    Website: www.clusos.com
    Prop Tools (Index) , Emulators (Index) , ZiCog (Z80)
  • jmgjmg Posts: 13,355
    edited 2018-11-16 - 21:12:08
    Cluso99 wrote: »
    Peter said it was a 3V3 oscillator.

    If the (same?) effect you and ozpropdev observe, is on Oscillator modules, that rather eliminates any Xtal-issues. Which becomes more of a worry.

    The code in #1 seems to be CC=%11 ? ( ie for 30pF Xtal)
    %CC     XI status       XO status       XI / XO impedance       XI / XO loading caps
    %00     ignored         float           Hi-Z                    OFF
    %01     input           600-ohm drive   1M-ohm                  OFF
    %10     input           600-ohm drive   1M-ohm                  15pF per pin
    %11     input           600-ohm drive   1M-ohm                  30pF per pin
    

    External osc is probably best as %01, but at 12MHz, 600 ohms and 30pF is tolerable, so should not do anything marginal ?

    You/ozpropdev could maybe scope XO to check ?

Sign In or Register to comment.