tonybarry

Members
  • Content count

    7
  • Joined

  • Last visited

About tonybarry

  • Rank
    Newbie

Contact Methods

  • Website URL
    www.tonybarry.net

Profile Information

  • Gender
    Male
  • Location
    Sydney, AUS
  • Interests
    astronomy, occultation observing
  1. Well well well, it seems Digilent actually HAS a R2R resistor ladder which will eat at 25MHz - this is $4.99 and requires no programming :-) Called a PMod R2R ... yes there will be digital glitches mixed in with the actual digital stuff, but that can be filtered with 2-pole Butterworth RC. Tony Barry Sydney, Australia
  2. @jpeyron, Many thanks for your informed answer. Much appreciated. I will need some GPIO to get associated stuff working (the GPS has serial in and out, and a1PPS signal that needs to be on a fairly low-latency input (I presume the concept of interrupts are available on FPGA). So the board with the most GPIO looks the nicest :-) The PModSD card is very nice. I haven't hit the specs hard yet. And I am hoping that the SPI bus is up for high speed writes - these serial buses traditionally have lower limits. But part of the reason I am doing this project is to get myself up to speed as well :-) @Dan, The DAC may require a different part - the PModDA1 will max out at about 500kHz and video really needs 6.5MHz + something to clean out the digital spikes. However this is not part of the original question, and it is very good to know what is available off-the-shelf for the Digilent parts. I think that rolling a DAC from a buffer and a resistor latter (yes that sounds like self abuse) might even be good enough for an initial sanity check. Anyway, a big thank you to you both for your interest and comments. Regards Tony Barry Sydney, Australia
  3. Thank you @jpeyron for your comments. In view of the requirements, are there any boards which have a better feature set for this project ? Or are you working purely on the basis of cost ? I would hope that respondents would be able to advise me something along the lines of :- <suggested format for recommend> Yes, Board X will do your job as it has enough RAM and a good enough clock to do your I/O. It might not do the DAC as well, due to bandwidth constraints. Board Y would do the bandwidth for DAC as well as the rest. The SD interface is doable by all the boards. The power requirements are met by all our boards. For any added computations you might need Board Z as it also has a Widget AA which will let you perform arithmetic at the speed of light. Cost for a dev board will be higher than your target price, but production costs will be within your stated reach. </suggested format for recommend> If you have any thoughts along these lines, I would be very grateful to hear them. Regards, Tony Barry Sydney, Australia
  4. Hi Dan, Yes, the video stream is monochrome (i.e. greyscale) and contains no colour information. I believe that most framegrabbers / video in cards do require the colourburst on the front porch to operate successfully. So for any DAC out I will need to provide this. Regards, Tony Barry Sydney, Australia
  5. Hi Dan, Thank you for your posting. The camera fortunately provides a digital stream already. It clocks at 28.656MHz, which is fairly fast, and is an 8-bit parallel path with two signalling lines (one for hSync, one for vSync). The interconnect can't be longer than about 50cm (18inches) unless it's an impedance matched path. Regards, Tony Barry Sydney, Australia
  6. Hi @jpeyron, The 3v3 point can easily be solved with an octal voltage buffer. My main interest is in the "horsepower" needed to move memory around, and keep up with the traffic in and out. If there are any compute cycles left over then I can use them to good effect by doing some stats on frames and performing a "digital stack" (i.e averaging across time). As an aside, I will have a GPS unit in there to provide a decent timebase for recorded image timing. Regards, Tony Barry Sydney, Australia
  7. Howdy to the Digilent-using people, Tony Barry writing. I am new to FPGA, but have a fairly strong background in EE and microcontrollers, C and assembler (mainly x86 but also Atmel AVR). My project is pro-bono for the amateur astronomy (occultation observing) community. Briefly, the occultation community observe the passage of asteroids in front of (generally dim) stars, and time the moment of eclipse and the moment of reappearance using strict UT timestamps to determine the position and possibly the shape of the asteroid from the knowledge of the time of the event, and the position of the observer on the earth. This information is passed on to the Minor Planet Center in Arizona for making improved ephemerides of asteroids, and sometimes to other science folk for various reasons. One recent occultation that gained some press was that of 2014 MU69 (the next target for the New Horizons probe after Pluto). You can read the story in the science press here:- https://www.space.com/37221-epic-success-observing-pluto-probe-next-target.html http://pluto.jhuapl.edu/Mission/KBO-Chasers.php Anyway, on to the point of this post. The limiting factor in occultation observing is the ability to see the target star (yes, that's obvious ... ) and there are two determinants of how dim a star you can see. Dimmer stars require bigger telescopes, and/or higher quantum efficiency cameras with lower noise. Amateurs do not have access to the budgets of professional scientists, so the telescope size is limited both by cost and by the ability to physically move a large heavy telescope. The camera cost is also limited. Within these constraints, it has been found that (arguably) the Watec 910BD board camera is pretty well the best (it was *not* used by the Johns Hopkins guys, but that's their story). However, the BD has some issues. The biggest issue is that it is a composite analog video camera (and that's ugly). Analog video really ought to be in the museums of this world ... but the cam can detect magnitude dimmer stars than comparable or more costly digital devices. However, the cam does have a digital video port, whose behaviour is documented, and this is the subject of this post. I would like to interface to this port. It is a BT.656 lookalike, which runs at a slightly higher clock speed (28.7MHz, vs 27MHz for standard BT.656) with 8 bits of data and two signal lines for vertical and horizontal blanking. 3V3 signalling and data. I need to pull in at least 16 frames (i.e. 756 bytes = 1 line x 525 lines = 400kB * 16 frames = 6.5MB storage) from this port, and do some arithmetic on those frames (basic averages, stats, etc), then shovel them into a UHS SD card or SSD local storage. It would be nice to have enough horsepower to do DAC and create some composite video out as a sanity check and local monitor. Now ... what kind of FPGA do I need to do this ? 1. Can run at more than 30MHz clocking in 8 bit parallel data. 2. Can store 10MB on board, and retrieve 1MB / sec from that store. 3. Can write 1MB / sec to an 8-bit DAC (the DAC can be an add-on, does not need to be on-board for this task). 4. Can write 1MB / sec to an UHS SD card (the socket can be off-board too). 5. Can run on 3V3. 6. Should not consume too much power. 10-12W would be around the maximum. 7. Cost is a consideration. Ideally, the FPGA would be less than $150 due to budget constraints. Well, that's my story. If anyone has some thoughts on the matter, please feel free to advise. Regards, Tony Tony Barry Sydney, Australia