Jump to content

engi

Members
  • Posts

    30
  • Joined

  • Last visited

Posts posted by engi

  1. When first starting the AD2 recently I though it was dead because I did not see a reaction. Now i discovered a heavily flashing green LED when look from aside into the plastic housing. Is that ok that way? I did not find anything mentioned about that in the docs.

     

     

  2. Hm, I got stuck with this issue too at first - later i managed that. As there are many login protections in the net which are really much worse than that , i am quite ok with that one in here.

     

    However I am with you that it is really frustrating! What some "programmers" and "webdesigners" consider reasonable to install as a "protection" is nothing more that user distraction.

    They mostly have not the brain to look forward to possible issues and traps because most of these guys have chaos in their brain.
    I have to deal with their "output" every day!

    When I get stuck to long I tend to sent a preprepared letter (as a paper!) to the company. I already complained at a CEO about a guy's nasty support and asked him if he himself is able to supply the data sheets of the products I was seeking for. Well, finally they reacted. :-)

     

     

     

  3. Interesting subject. I am going to use AD2 for audio too, whereby I wonder about the quality of input noise. Generally I would go with a good sound card or a professional device. Also for the microhones i suggest a noise free pre amp with a good and noise free 48V phantom power.

    Me I am going with RME' ADI Pro and fireface. For Audio analysis I use ARTA, and selfbuilt gear.

    Regarding AD2, I wonder about the linearity of the frequency curve. (?)

  4. With an Artix it is possible to treat UHD at 297MHz, most probably not with an analog VGA:-)
    In the example above, I am using 148.5MHz for HDMI, which is already pretty high for analog purposes.

    With a Spartan I also used 148.5 and also 162 to drive 1600x1200. The issue here is the monitor which only prints nice at 1920x1080, so there is no other choice at first glance.

    With a different timing scheme it might be possible to go with almost 200MHz, but did not try this. See the table below.
    https://www.mikrocontroller.net/articles/Projekt_VGA_Core_in_VHDL

     

  5. I checked the alignment and some wrong CCs wont do much harm ecept of an image shift. The issue I was describing above was indeed the missing active area treatment: When stripping down the example, I simply did not blank the VGA outs correctly. However I will check the alignmet again - but according to a test I did in the meanwhile (using a frame of 1 pixel width) this is right.
    Here is an example of a vid pattern (ARTY 100, PmodVGA placed at ports B+C)

     

     

     

    vga_pattern_test.zip

  6. ********************

    The issue is solved!

    ********************

    It was a specific problem with the monitor and the pattern I was using: If one looks close to the pattern one can see the effect that the colour already slightly changes over the vertical coordinate!  Reason: The Monitor scans the VGA signal in order to get the limits for VMAX and blank and with my pattern this worked only partly. I did not correctly blank the VGA channels in the HSYNCH and VSYNCH periods. Regarding the code above, the "active" signal has to be taken into account. Then it works fine.

    And yes:  No power supply is required for this design. It works without.

     

  7. For an appropriate processing of a MEMS PDM datastream (not I2S data stream)  a good filter is required. Averaging only will cause a lot of alias frequencies to pass the filter.
    The same is with the Hogenauer CIC (often called SINC) which is not a good SINC at all.

    A cost effective Filter can be built in any PLD with an IIR like this:

    SUM = (65536 * NEW  + 1023 * SUM) / 1024

    leading to Value with 16 Bit quality and an edge frequency of ~/512  (for a <5MHz PDM here around  10kHz).

     

     

  8. On 9/15/2019 at 3:15 PM, maziiz said:

    I use MCLK = 25 MHz , LRCLK = 48.8K hz , SCK = 3.128 Mhz 

    LR clock seems to be wrong. This should be the half i think, since it toggles with the 32 bits of a word indicating the same channel (L).
    for MCLK some devices requires 128xLR Clock, some 256x.

    For those reading the thread:

    I recommend to use an appropriate audio clock, which can be achieved with a PLL like this:

    PLL 1 : 100MHz -> 2:8 -> 25 MHz

    PLL 2: 25 MHz >  29/59 ->  12.288 MHz   which is only some ppm away from the ideal frequency.

    The resulting Frequency should be :  LR Clock 96kHz   / MCLOCK 12.288 / 25.576    - Sample FR = 48.000.xx  kHz

    Leaving PLL 1 away would be appropriate für 96kHz / 192kHz Audio.

     

  9. Not sure if it heps, but I wonder, how the PLL setting should cooperate with I2S.(?)

    Typically you will get or drive the MCLOCK from / to the board with 64xBCLK. This is for instance someting like 12,288 MHz. One chance is to obtain a BLCK and use a PLL to generate an internal multiple of it to get e.g. S/PDIF (BMC) working.

    If you want to produce I2S or S/PDIF from the PCB and do not have an oscilator with 24.576...  you can try to produce a 25MHz Clock with a first PLL and then use a 29/59 to obtain a 12,288 with some 20 ppm error only!  One can even use a little load to the OSC to pull it and synch it to an coming clock this way.

×
×
  • Create New...