• Content Count

  • Joined

  • Last visited

  1. Hey, thanks. Yeah I can try a different padding character, but I was under the impression FF was the best because even if the receiver is out of sync, it will still sync since it will think the FF byte is just IDLE state. By the way, that reasoning of using an FF byte for padding opposed to an AA byte is addressed specifically in the 2nd answer by "MikeJ-UK" to a question on serial UART, on stackexchange. The baud rate is a little weird, it's 781,250. That's because I'm dividing down from the 100MHz clock on the Nexys 3. I have a PMOD running at 195 kHz that essentially outputs new samples every 22-ish cycles of the 195k clock I need to transmit about 85-ish bits successfully in between those samples arriving, which means I have 112 microseconds, or about 1.3 microseconds per bit. 781.25 kHz is 100Mhz / 2^7, comes out to 1.28 us, so it's the closest I can get. In that case then, I don't think those packets should be BREAKs, because the signal rises back to 1 before the next packet starts.
  2. Using the analog discovery with waveforms 3, it seems like the UART interpreter is telling me things that are incorrect. I could be completely wrong, and maybe I don't know enough about UART framing to tell, but if that's the case let me know, The data stream I am sending is arranged like so: [FF pad byte] - [data(lower 6 + 2 tag bits)] - [FF pad byte] - [data(upper 6 + 2 tag bits)] - [FF pad byte] - [checksum] To get a much better look at the bits, go to: Then hover over the image at my photobucket, and click the zoom icon that appears in the top right. As you can see, those bits appear to be there, correctly, but the interpreter doesn't seem to think so. Byte 1, the first FF, is recognized successfully. Byte 2, the first data + tag bits, is marked as "Framing Error". From what I understand, framing errors occur when the STOP bit does not occur at the correct time. Clearly however, the STOP is bit is there, as the signal is HIGH where STOP is marked. Byte 3, the second FF, is recognized successfully. Byte 4, the second set of data + tag bits, is marked as "BREAK". What this means, I have no clue. The line drops low after the last FF so why isn't this recognized as a new start bit? I also believe that set of bits is correct. Byte 5, the last FF, is correct. Byte 6, the checksum, is also marked as "BREAK", yet appears to correctly be there. Also, this interpretation is heavily dependent on my time scale. The above image is at 0.01ms/div (20 MHz) At 0.02ms/div (10 MHz), the "BREAK"s go away, and are replaced with framing errors (still, seemingly incorrectly). And you can CLEARLY see that bit #7 in the second packet is a 1, yet the interpreter tells me the value is "h0" Finally 0.05ms/div(4MHz) All the errors are gone, and the 2nd packet is supposedly an h80
  3. Thanks for the help, hamster. I got this to work surprisingly, and I am successfully reading in some data to a python script. It works similar to the script you sent me. While I was getting this working, I encountered something interesting on my Analog Discovery that I'm making a separate post about, and I'll link to it from here.
  4. I've got the Nexys 3 board and it's reading some data from a peripheral, but I can't debug what's on the board because I'm not about to spend 600+ on chipscope. So I've thought about the possibility of using the UART to send data back to the PC to analyze there, but the problem is there's really just about zilch information out there on how to use the UART on this board. Let's be honest, the Digilent Nexys 3 user guide (pg 12) is absolutely useless in this regard. It explains what the UART does from a high level, and mentions using free FTDI drivers, but has absolutely no information whatsoever on how to actually use this feature. I've tried approaching this at a xilinx angle, searching for "UART cores", which are hard to find, potentially not free, and not simple to actually implement or use. (I managed to acquire a "XPS 16550 UART" license, but can't figure out the first thing about how to use it, since Xilinx loves to massively overcomplicate what should be simple instructions) So I'm abandoning that approach, and now I'm here. Shouldn't there be an easy way to get, this UART up and running?
  5. I recently purchased the PmodMIC to use with my Nexys 3 board and Analog Discovery. Finally after a bit of coding, I seem to have gotten it to run continuously, but I have just a few questions. In the PmodMIC reference component PDF, it states: The VHDL component is an entity named PmodMicRefComp which has five inputs and five outputs.The input ports are a 50MHz clock,.... (BTW, I think the 5 inputs, 5 outputs thing is a typo ). But my first question is: 1) Is it possible to lower the sampling rate? Apparently the 50 MHz input clock gets divided down to 12.5 MHz inside the PmodMICRefComp. I need to record some audio data, but certainly not at 12.5 MHz! I am not sure why any audio source would ever need to be sampled that quickly, but in any case, I attempted to lower the input clock speed down a bit and my design seems to have failed. I am looking to record signals comprised mainly of human speech, so 8KHz is actually about what I need. The 2nd question is: 2) I see no mention anywhere of the format of the data output by the PmodMIC. It's 12 bits in parallel, but is that signed? unsigned? Couldn't seem to find this in the reference PDF anywhere. If this is an SPI standard convention that I'm just not aware of, sorry for asking. The 3nd question is: 3) In the state machine diagram, is there no transition directly from the "SyncData" state to the "ShiftIn" state? My code currently initiates continuous sampling by checking if nCS is HIGH and DONE is low, as indicated in the SyncData state. Then, it brings the START signal low again to return to the IDLE state, and increments a counter to keep track of the number of samples taken. On the next clock cycle, it checks if START is low, and # of samples is > 1, then pull START highagain, repeating the process. What I am wondering is: Instead of pulling START low to return to IDLE, would it not just be possible to keep START high and have nCS get pulled low again? I suppose this would need to be taken care of by the PmodMICRefComp VHDL code since that is the driver for the nCS signal after all. It would be nice if that provided VHDL component had a single bit control signal that allowed for selecting ONE TIME conversion and CONTINUOUS conversion. Thanks for taking the time to read this.
  6. Very cool! Thanks for the answers. WF3 definitely looks like a step forward from WF2, that's for sure. Though how does the device manage to stream to 1 million samples when it can only handle 16K internally? Does it attempt to transfer to the PC while more samples are being taken? If you folks at digilent are ever thinking about redesigning the Analog Discovery for a 2.0 edition, I would certainly be willing to pay more money for either 1) a larger internal memory to store more than 16K, or 2) the ability to truly stream the samples to PC (USB 3.0?), and thus only be limited by the amount of PC ram I possess. I am not sure what the realistic capabilities and limits are of USB 3.0 but surely there would be an equilibrium sampling speed that could be attained indefinitely while transferring over the the PC. Thanks again attila!
  7. I think you make a good case. Fortunately for me, I am a student and got the student pricing on the Analog Discovery, but before I purchased it, I was also looking for a fairly cheap option ($100 - $150 range), and came across the Saleae selection. If it were not for the faster sample rate of the Discovery over their equivalent $100ish choice, I might have picked the Saleae. But I think you are right, I think there is a demand out there for a cheaper analyzer with limited functonality.
  8. Thanks, that clears up a lot. If you don't mind, I have a few other questions if you can answer them. What is the difference between the two versions you have linked in your PM? Is the version 3 just a beta? Patch notes or change log anywhere? Also, another quick question regarding a specification of the Analog Discovery. The specs state it is capable of 16K transitions per pin. So this is an internal buffer limitation on the device? Yet I am not limited to just a single buffer, and can specify many buffers to be filled in WaveForms. Is there a limit to how many buffers I can specify? And why are these logically separated once they have been transferred to the application on my PC? I only ask because it seems rather tedious to even think about the concept of filling over 6,000 buffers per second at 100 MS/s, and having to dig through all of these. I get the corresponding limitation on the device, but it seems like something that could/should be abstracted away from the end user. AKA - one single timeline from start to finish that contains all my samples. Just my thoughts. And thanks again.
  9. I just bought this product recently. It looks pretty nice, and I'm pretty sure I'm not using it to its full potential. The specs say it samples at 100MS/s, yet that certainly is not happening with mine. From the looks of it, I see 2048 samples at 4.005 kHz. And by counting the marks between the time divisions (1ms apart), it does look like approx 4kHz. Why is this not running faster? This is a far cry short of 100MS/s. I also see no setting anywhere to change the sampling rate/speed.