S/PDIF, AES3 generation for Prop2?

Just wondering if anyone's done a version for the Prop2 yet - I note a Prop1 implementation from a while back using the
video generator, but clearly that's not a direct match.

And of course a receiver for these would also be interesting...

__Mark

Comments

  • S/PDIF is digital audio, right? That should be trivial...
    AES3 I don't know... Is that encryption tools?
    Prop Info and Apps: http://www.rayslogic.com/
  • Rayman wrote: »
    S/PDIF is digital audio, right? That should be trivial...
    AES3 I don't know... Is that encryption tools?

    Both are serial transmission of digital audio:

    https://www.rane.com/note149.html
  • jmgjmg Posts: 13,901
    Mark_T wrote: »
    Just wondering if anyone's done a version for the Prop2 yet...

    Multiple versions, but the coax version is similar to the Video DAC params, and the encode could be via 16b wide LUT, so send looks doable.
    I think the P2 pins have a threshold DAC mode, so they might be able to receive the coax data maybe with some amplitude-sense.


  • The part that makes it tricky is encoding/decoding biphase mark encoding fast enough. At least with the asynchronous smart pins, maybe you could keep handling them in chunks of 16 bits at a time (32 bits encoded).
  • jmgjmg Posts: 13,901
    PaulForgey wrote: »
    The part that makes it tricky is encoding/decoding biphase mark encoding fast enough. At least with the asynchronous smart pins, maybe you could keep handling them in chunks of 16 bits at a time (32 bits encoded).

    Yes, I think encode is not so hard, where you can use the LUT to do 8 data bits to 16 modulation slots & I think that can streamer feed too.

    Going the other way is tighter, as you need to somehow edge-sync, and receive at the same time.
    Maybe a combination of Edge-Event, and a prop-generated clock, (costs 1 more pin) can sync-sample the incoming data ?
    Sync receive of 8 samples, from 8 modulation slots could decode 4 data bits via LUT the other way.
  • Receiving is indeed harder as you need to phase-lock the system clock to the recovered clock if you want to drive a DAC
    and get decent performance, or else implement a FIFO with as much SRAM as you can afford. Being able to switch from 44.1kSPS to 48kSPS with accurate clocking isn't so simple either (nor is rate conversion between them as the ratio is 160:147)

    For generation I've got an inner loop thus:
    do_bit          shl     data, #1
                    shl     pattern, #2
            if_c    add     data, #1
            if_c    add     pattern, #1
            if_nc   not     pattern
                    ret
    
    where the data register is used for determining the parity, pattern is the biphase/mark.

    That should handle upto about 10Mb rate, and 48kSPS only needs 3Mb or so. Byte lookup would be needed for 192kSPS I think.
Sign In or Register to comment.