• Content Count

  • Joined

  • Last visited

About CharlesS

  • Rank

Profile Information

  • Gender
  • Location
    : Bremerton WA
  • Interests
  1. Oh! So that's the issue. Good to know. Guess I'm too accustomed to plain ol' regular C, where functions only return one value. Incidentally, my incorrect scheme was derived directly from the example script built into WaveForms. e.g. look at the "Pmod GYRO - L3G4200D" sensor script under "protocol>i2C" (Using WaveForms Version: 3.7.5 64-bit) On a tangential note, It would be really cool if there was a comprehensive guide for the javascript API. The inbuilt help is... well... "lacking" to say the least. Anyway, thanks for looking at this and thanks for the catch. I'll try and fix the posted script sometime soon.
  2. Note To Staff There is no need for help here; I just wanted to share this with others, since it was useful to me. As far as I'm concerned (have power to say?), this code, text, graphics, and attachments are all public domain (preferably with attribution). If there is a specific area or protocol for these sorts of things, I haven't seen it. This post and contents could be stickied, moved, and otherwise used as the powers that be see fit. If there is something wrong, something that needs changed, or something the needs clarified, feel free. /Note To Staff Hello all. I have a small gift for anyone that wants it. The following is working javascript for GY-521 breakout boards, which holds the venerable InvenSense MPU-6050 6 axis IMU chips. // -UNOFFICIAL SCRIPT- -AS IS- -NOT ENDORSED BY DIGILENT- -USE AT OWN RISK- // Author: Charles Scoville // // GY-521 breakout board: InvenSense MPU-6050 i2C Gryo + accelerometer // Set clock = 400kHz: Rate up to 400Hz (more may work): Itterations ~1k const adr = 0x68; // 0x69 is an alternate address. function initialize(){ if(Clear()!=true) return "I2C bus error. Check the pull-ups."; if(Write(adr)!=true) return "Device NAK"; //if(Read(adr, 0x75, 1) != 0x68) return "Device ID mismatch"; *FIXME* Read() bug? Does NOT actually return 0x68 if(Write(adr, 0x6B, 0x03)!=0) return "Communication error"; // REG: PWR_MGMT_1 (Z gyro as clock source) if(Write(adr, 0x23, 0x78)!=0) return "Communication error"; // REG: FIFO_EN (FIFO only for Gyros and accelerometer) if(Write(adr, 0x6A, 0x45)!=0) return "Communication error"; // REG: USER_CTRL (Reset FIFO and signal paths for all sensors) if(!FileWriteLine("~/Desktop/default.csv", ["temp", "ACCEL_XOUT", "ACCEL_YOUT", "ACCEL_ZOUT", "GYRO_XOUT", "GYRO_YOUT", "GYRO_ZOUT"])) return "File write failed - init"; return true; } function loop(){ var rg = Read(adr, 0x3B, 14); // DATA var xa = ((rg[0]<<24) | (rg[1]<<16)) /256/256; var ya = ((rg[2]<<24) | (rg[3]<<16)) /256/256; var za = ((rg[4]<<24) | (rg[5]<<16)) /256/256; // NOTE: REG 0x23 must be written as 0xF8 for temp to be buffered var tmp = ((rg[6]<<24) | (rg[7]<<16)) /256/256/340 + 36.53; //temp (deg C) //tmp = tmp * 1.8 + 32; //temp (deg F) var xg = ((rg[8]<<24) | (rg[9]<<16)) /256/256; var yg = ((rg[10]<<24) | (rg[11]<<16)) /256/256; var zg = ((rg[12]<<24) | (rg[13]<<16)) /256/256; if(!FileAppendLine("~/Desktop/default.csv", [tmp, xa, ya, za, xg, yg, zg])) return "File write failed - loop"; return true; } function finish(){ return "done"; } This script is to be used in the "protocol>i2c>sensor" section of the WaveForms application. I have only run this on the Electronics Explorer, I have no idea if it even applies to anything else. The results when run (with a GY-521 attached, of course!) are a CSV file on your desktop, just as with the PMOD gyro or accelerator example code it was based on. For this data capture to make much sense, you will most likely want to graph the columns in the resulting file. I did so for the accelerometer and gyrometer as independent groups, as that provides the most informative and expected form for the data. The following are some graphs of a couple of my more interesting captures, as examples. They were made with LibreOffice 6.0 directly from the CSV files. The ods files are also attached. (Embedded malware is thoroughly unlikely, but you still open at your own risk.) This one was just me picking it up and turning it all around. It's a nice shot because it's pretty obvious when I picked it up, and what exactly I did. This one was of me lifting the board up onto one corner, rapidly twisting it back and forth, then just setting it down. This one clearly has more samples too. Anyway, thanks for reading. I hope this post has value to you. MPU-6050 readout1.ods MPU-6050 readout2.ods
  3. Hi, Simply put; how can I directly measure a component's voltage drop using the inbuilt oscilloscope without pulling in another independent/isolated/floating power supply? (I am expecting I can do this using two scope channels and some feature of WaveForms that will extract the difference, yes?) The experimentation manual for my EE class wants me to measure the AC voltage drop of a component in the middle of a circuit, in this case a resistor between two other resistors. The problem is the scope ground and power supply ground on the EE board are apparently hardwired together, so I can't measure the voltage across anything that isn't already grounded. I can only measure the voltage at a node with respect to ground, which is insufficient. Note that if this were not an academic project I would probably just calculate the differences in voltage manually and be done. Unfortunately, If I am given a parameter to fill with a measurement, I am required to actually take the measurement. In contrast there are parameters that I must fill by doing the calculation, and I absolutely must not take measurements.
  4. Agreed and seconded. Something like the inverse of the Analyzer's interpreters. Any reasonable interface that would allow for a spectrum of pre-baked com blocks: e.g. i2c, SPI, i2s, PS2, lv RS232, Jtag, Hitachi HD44780, memory parallel (address+data bus), etc. would be a godsend. I have drawers full of various chips, such as EEPROMS, that would be nice to be able to debug/dump/write from the same prototyping platform. Having this in Waveforms would allow me to do such things from my Electronics Explorer board instead of resorting to custom building a temp MCU project each time.
  5. Ah! I see now. Hooray for programmable logic Interestingly, I used the search on the left of WaveForms help for the keyword "buffer" and the page that explains device manager never showed up. (I guess that the find text box is different from Ctrl+F) If that wasn't enough, I had already read the page in question, but apparently didn't really take in that particular piece of info. Hindsight is 20/20 I guess.
  6. Hello all, I'm experimenting with IR remote protocol using an IR LED and a typical TSOPxx38 IR receiver, all on the Digilent Electronics Explorer board, and I am in need of a work around for sending more than 512 bits on a single DIO channel. I have searched through WaveForms' help and could not find anything of use on this. Synopsis Typical IR coms work, in principle, identically to ON/OFF keying in radio. That is, an IR receiver sees a logical 0 as the absence of the carrier, and a logical 1 as the presences of the carrier. The difference from radio being that the carrier in IR coms is realized as an IR light flashing at 38kHz. The actual intelligence is sent as varying lengths of carrier/no carrier to construct higher-level 1s and 0s. I will label those here as "mark" or "space" tokens or symbols. I am trying to emulate this process using WaveForms' Digital Pattern Generator via the Electronics Explorer board and a single DIO pin. Efforts The first thing I tried was to configure a pin as a 38kHz clock and send pulses by simply running or stopping the Digital Pattern Generator. This emulated the carrier properly; the IR receiver indeed changes logical state when the DPG was enabled/disabled. However, this does not allow algorithmically controlled mark/space patterns to be sent, such as what you would see with a button press on a TV remote. Next, I tried to set a custom signal type, pre filled with alternating 1s and 0s. Then, to construct a high-level pattern, I simply copy and paste 1/0 blocks for mark, or high-Z blocks for space. This worked as expected, and the high-level pattern I create does indeed show up on the IR receiver output pin. The problem is each 1/0 block is composed of several bits, consuming a rather large portion of the buffer. If a mark consists of 32 bits, and a space consists of 32 bits, I can only send about 8 tokens/symbols with the given buffer size. Since a typical consumer electronics remote may send something around 10~25 symbols, this method proves to be inadequate. My final idea (something I have yet to actually try) would be to use one DIO as a 38kHz clock that is constantly on, and a second DIO plus some switching component (read:transistor) to either pass or block the clock to the LED. This would let me use the full 512 bits of the second DIO channel to send the marks and spaces. This idea leaves a sour taste in my mouth though; I feel that this platform should be able to do this simple a task no sweat without me having to resort to adding such hardware hacks. Final Thoughts According to the EEBoard's datasheet, the device should have "... up to 16KSa per pin buffer depth." This is great... but what exactly does this mean? Where is this "16KSa per pin?" Because I'm not really seeing a way to send 16Kb on one wire. Seems to me this 16KSa is actually the 512 bit buffer per pin, times the 32 pins. So really it looks like it should say something like "512Sa hardware buffer per pin, for up to 16KSa total buffer size," or similar. I have searched through WaveForms' help and could not find anything of use about this either. Clarification on this last point, and help in general, would be greatly appreciated. Thanks. -Charlie
  7. Oh, cool. That also happens to explain why my LED is a bit dim. I was thinking I was maybe overloading the pin, and thus, seeing a voltage drop off the sourcing p-FET. But I guess I just needed to account for the PTC resistance in my LED current calculations; that's excellent. I was actually a bit upset because it looked like the EEboard didn't have any protection for the DIO, but all those ~0603 resistors in a row are actually polly fuses eh? ... Good to know. Though, I think I still would have preferred socketed buffer IC's myself. In any case, thanks for the info. -Charlie
  8. Hello, On Digilent's EEBoard, what is the max safe sink/source current for any one digital I/O pin/channel? An internet search, and parsing the Spartan 3 datasheet, suggest 8mA per pad/pin. If so, that's really unfortunate; I'd rather not have to buffer this 10~15mA IR LED if I can avoid it. -Charlie