S
Reaction score
7

Latest activity Postings About

    • S
      Oh no, we are using small circular or rectangular cells. Two cells between 70 and 120 mA-hrs each. They are on the order of a cubic centimeter each. We are severely space and weight constrained, so it's a battle between more complex circuitry...
    • S
      Interesting. This will be at room temperature, where I find that the battery ‘knee’ is about 3.2v. So if take it down to about 3.35 or so, the 3.3v regulator can still work and I’ve pulled just about all the energy out. Discharge tests using that...
    • S
      Good idea, but in this design, I will be running off a lithium battery (which is why the current difference matters so much). In that case, it’s pretty much a wash in efficiency between the two. I suppose a buck-boost would allow me to drain the...
    • S
      Thanks! I tried it and no change, as you expected. But I'll be sure to add that to the next iteration. One other difference is my board does not have fuse, ferrite, or FET in the VUSB line. Should not matter, but it is a difference.
    • S
      I checked various voltages and they all look similar to the T4.1, except, on my board, NVCC_PLL was 2.52 volts, where on the T4.1 it is 1.11V. I realized I had a 4.7uF cap in parallel with the 0.22. I removed the 4.7 and the voltage dropped to...
    • S
      Oh sorry, it shows ok on my monitor. The processors that are installed are identical part numbers though. Good eye on that -fixed. It is probably something that simple. I'm attaching the Eagle files if that's helpful.
    • S
      I've been working on a custom board based on the T4.1. During development I have had several issues, but these are mostly resolved. One item though has been really difficult to suss out. The current draw is a good 10mA higher than a stock T4.1...
      • 1771781337912.png
    • S
      slash2 replied to the thread Fast Data Logger.
      I'm trying to have it do nothing else during data collection, but that's a good idea to keep in mind.
    • S
      slash2 replied to the thread Fast Data Logger.
      I sent the data to the person that is writing the host code to check it, but from the checks I have done it looks good. I will be running more tests, with various cards, looking at buffer and battery usage. I will report back. I'll also sum up...
    • S
      slash2 replied to the thread Fast Data Logger.
      Of course! The interrupt delay gives me plenty of setup time. As it turns out, the way the FPGA code runs, your idea misses the first data value, but I just changed the clock sense in the FPGA so it goes high when the data is changed - so same...
      • 1771270682204.png
      • 1771270829697.png
    • S
      slash2 replied to the thread Fast Data Logger.
      HA! I think I figured it out. My FPGA sets up the next data and sets the data clock low. Then, half way to when it is time to set up the next data, it sets the output data clock high. The Teensy clock interrupts on the rising edge of the data...
    • S
      slash2 replied to the thread Fast Data Logger.
      I looked at that a bit, but, in my understanding, DMA can only access the slow version of the registers. I don't think that would be fast enough.
    • S
      slash2 replied to the thread Fast Data Logger.
      Well, dang. I thought I had read that higher was higher priority. Good catch! I wonder if I could also disable the systick_isr - I imagine it would only impact things like 'delay', which I can work around. UPDATE: I changed the priority, but...
    • S
      slash2 replied to the thread Fast Data Logger.
      Yes, I did exactly that, and at the end I programmed the teensy to read the file and compare stored values against a counter in the loop. This was on a stock T4.1. It reported no errors. My next step is to run it on my board, then, if that is...
    • S
      slash2 replied to the thread Fast Data Logger.
      Yes - that is the time within the ISR and does not include the latency to call the ISR (and to return) I had set a pin high at the beginning of the ISR and lowered it at the end. And then subtracted the time for digitalWriteFast (about 4 nsec) to...
    • S
      slash2 replied to the thread Fast Data Logger.
      Certainly! Here is the code - I removed a bunch of debug stuff at the end where I do various data checks, as well as comms with the probe, as I don't know if that interface is fully released to the public yet. But you can run the code on T4.1 if...
    • S
      slash2 replied to the thread Fast Data Logger.
      Yes, it is probably time to ask for help on that. I wanted to be sure it wasn't a card or probe problem first, and I think they are no longer suspects. -Writing from an ISR, reading from the main loop. - I believe it is, but I've been known to...
    • S
      slash2 replied to the thread Fast Data Logger.
      I graphed a discharge curve while logging to a V90 card. I used two 70mA-Hr lithium batteries paralleled through ideal diodes. Even though I only took data every ten seconds, you can see voltage dips that look pretty regular and I imagine those...
      • 1771102775235.png
    • S
      slash2 replied to the thread Fast Data Logger.
      I bought a high card SD Card 0 Delkin V90. Rated at 300MB/sec. I assume that is using it's UHS-II interface. But I figured it should have lower latency. I tested it with joepasquariello's latency test firmware for 1.2 hour at 18MB/sec and sure...
    • S
      slash2 replied to the thread Fast Data Logger.
      I believe so! Now I just need to see if the data I'm storing is right.
    • S
      slash2 replied to the thread Fast Data Logger.
      I ran both cards with your code. I had to make the buffer on the 18mb/s = (DATA_RATE_BPS / 84) The card matters greatly, even though both are V30. Card SD Industrial SD Express Plus SD Industrial SD Express Plus Speed (mbytes/sec) 10 10 18...
    • S
      slash2 replied to the thread Fast Data Logger.
      30 minute run: 36863999 writes in 1787.904 s (171.923 s writing to file = 9.616 %) File is full fileSize = 18874367488 before sync() rb.bytesUsed = 512 before sync() fileSize = 18874368000 after sync() rb.bytesUsed = 0...
    • S
      slash2 replied to the thread Fast Data Logger.
      Nice designs! I remember the TattleTale. I was in the oceanographic domain about 40 years ago. I did the firmware for the 8011 Deck Unit in Forth. Out of curiosity I just looked and they still make it! 8011
    • S
      slash2 replied to the thread Fast Data Logger.
      I believe so. I did a lot of testing at home and it had a somewhat older Arduino on it. That’s where the earlier charts came from. Then I updated to the latest arduino and teensy and removed the arduino/libraries/sdfat libraries just to be sure...
    • S
      slash2 replied to the thread Fast Data Logger.
      I updated my Arduino and Teesnyduino to the latest. Ran a half hour at 4.5Msmpl/sec (18Mbytes/sec) with the RAM1 and RAM2 buffer, though it looks like a single buffer would be enough. Buffer usage in bytes on Y and sample number /8100 on X. It's...
      • 1770685176867.png
    • S
      slash2 replied to the thread Fast Data Logger.
      I ran what I downloaded with my program and got: max Buf Usage (bytes): 533532 using a Dual buffer of 899072 bytes so theoretically it worked! I'll need to check the data, but this is encouraging. I'm using Teensy 1.59.0, which looks like the...
    • S
      slash2 replied to the thread Fast Data Logger.
      Yes- but now I see Paul’s fork on github. I’m trying that now. I had been using the one in the Teensy hardware libraries which I assume is the one included in Teensyduino, but maybe it was out of date.
    • S
      slash2 replied to the thread Fast Data Logger.
      I'm using: https://github.com/greiman/SdFat Should I be using something else?
    • S
      slash2 replied to the thread Fast Data Logger.
      "It's not what you don't know, it's what you know that ain't so" Well, this is embarrassing. I went to run SDInfo and it would not compile - there were several missing definitions. But I had updated the SDfat library and I pulled SDinfo.ino from...
    • S
      slash2 replied to the thread Fast Data Logger.
      ok - this is weird. I ran your code with a fully formatted card. I meant to change: #define LOGGING_TIME_S (480ULL) to 1800 to do 1/2 hour, but I mistakenly used 180 (3 minutes), but here is what I got - max busy us = 158505.48. Full...
    • S
      slash2 replied to the thread Fast Data Logger.
      Thanks - will do. And to jmarsh: I use the formatter provided by the SD Organization. it takes an hour fro a 256GB drive, so I hope it is doing some deep level cleanup. I can't access that part of their site right now so I can't check on details.
    • S
      slash2 replied to the thread Fast Data Logger.
      All good info. May have to get into the guts of this. I did a run with a fully formatted card. Still had the delays, which, if due to sector erases, means the card doesn't check to see if a sector is pre-erased. I get it- most people will not...
    • S
      slash2 replied to the thread Fast Data Logger.
      Ha! I remember the Rabbit - nice processor as I recall. I did the same on the data logger I designed 20-some years ago. The FAT overhead was too much, plus, I think, it still had a 2^32 (or 31?) max file size. I reserved a couple of sectors to...
    • S
      slash2 replied to the thread Fast Data Logger.
      I appreciate your persistence in helping me figure this out. What changes did you make for file size > 32bits? I did make the file size variable 64 bits. Maybe I’ve missed something.
    • S
      slash2 replied to the thread Fast Data Logger.
      I believe you said you were running at 10MB/sec? I ran at 6 with no problems, but failed at 14. I’d love to be wrong here. If you run a card using bench.ino for 15000Mb do you get the long latencies? I think I understand what that means - that no...
    • S
      slash2 replied to the thread Fast Data Logger.
      And that is the problem. It's saying that, in order to accommodate these rare delays, one would need 8Mbytes of buffer. I just ran bench.ino with a setting of 15000 Mbytes to ensure we would hit at least one of these delays: write speed and...
    • S
      slash2 replied to the thread Fast Data Logger.
      They axis is bytes of buffer needed- like in the other graphs, but not labeled here. The x axis is samples / 8100. Had to bin the data since Excel only allows 1e6 rows.
    • S
      slash2 replied to the thread Fast Data Logger.
      Oops - I should have expanded that. It’s 4.5 mega-samples per second with each sample being 4 bytes- so 18 Mbytes/sec.
    • S
      slash2 replied to the thread Fast Data Logger.
      I ran another test at 4.5Msmp/sec but I first did a full format with the SD Card organization's format program. Not encouraging (I didn't 'pretty' this one up). This seems to indicate a large latency could happen early in a logging session, so...
      • 1770578043061.png
    • S
      slash2 replied to the thread Fast Data Logger.
      Good info, thanks. So if the card is fully formatted, will the block erase be skipped? I should test that. What oceanographic company? I used to work at SeaLink which got bought up by EG&G. We mostly did releases.
    • S
      slash2 replied to the thread Fast Data Logger.
      We would like an hour - 64 Gbytes, but at the moment it looks like our battery setup will only give us 45 minutes, which is useable. We are limited by size and weight and cannot increase the battery. I’ve been pondering how to handle a buffer...
    • S
      slash2 replied to the thread Fast Data Logger.
      One file - 32GBytes. Pre-allocated. Quick format each time (full format on 256gb takes forever and I was running a lot of tests).
    • S
      slash2 replied to the thread Fast Data Logger.
      I ran a bunch of long tests today. I saved 30 minutes of data at 18Mbytes/sec. This is on the order of what I need - I am aiming for 1 hour at 18Mbytes/sec, but the tests take a long time to run and analyze, so I cut it back some. Some notes...
      • 1770513073924.png
      • 1770513898424.png
    • S
      slash2 replied to the thread Fast Data Logger.
      Those are really good times. And, yes, I see a lot of variation as well. I bought several new cards and tested them. All were supposed to be 30MB/s, though one had conflicting information (as I understand it). I also re-ran the ExtremePlus...
    • S
      slash2 replied to the thread Fast Data Logger.
      Ok, so I ran three cards. Results below. The three were: Sandisk EXtreme PLUS 256GB V30 SanDisk Industrial XI 128GB V10 Riverdi 'Grade A Micro SD' 4GB V10 All were fully formatted using the SD Card Organization formatting tool. Most notable...
    • S
      slash2 replied to the thread Fast Data Logger.
      In response to DRAM power - I don't know. In my particular case though I have neither the area or (probably) free pins to add it. On the test, I will run the tests in the morning.
    • S
      slash2 replied to the thread Fast Data Logger.
      Yes, I was seeing similar numbers on my cards- even Class I. The problem is that it’s an average. The card datasheets don’t tell you the maximum latency. That is they may plow along at 25mb/s but then do housekeeping for 50msec. That means you...
    • S
      slash2 replied to the thread Fast Data Logger.
      I may have described things poorly. I don’t send the entire buffer to the SD write routine. I send data to the SD card in 512 byte blocks. I treat the two memories as one large buffer. The input data clock causes an interrupt that saves the 32...
    • S
      slash2 replied to the thread Fast Data Logger.
      Oh sorry, my 40msec was based on what others had measured. I am seeing much less than that - so far. My data rate is 18mbytes/sec, so I’m seeing about 7msec. I’ll do a full hour test tomorrow with a fast card and let’s see what I get there.
    • S
      slash2 replied to the thread Fast Data Logger.
      Perhaps. Let's see what a one hour run looks like with a proper card. The dual buffer doesn't seem to hurt, so I may keep it any case. It's there , might as well use it. That's a nice design. However his SDRAM uses up the bus I need for my 32...
      • Chip side.png
  • Loading…
  • Loading…
Back
Top