Search results

Some more follow up: I had also skimped some on bulk capacitance. Bringing those up to the values recommended by NXP helped bring down current draw. Also using larger packages for the larger capacitances probably helps. It’s also important to have good thermal management in the PCB design. Our...

I found this from the NXP Hardware Development Guide: The recommended value for the external inductor is about 4.7u~10uH ，saturation current >1A，ESR < 0.2Ohm;

It looks like it's the 4.7uH inductor (L1). I used a Murata LQM18PH4R7MFRL to keep the size down as much as possible, but it must have too much series resistance (0.44 ohms). I had an EPCOS T1472K on hand which is a bigger part and half the series resistance and substituted it. The current...

I made the changes and added the MTP stuff in. I selected 'Serial + MTP' as I need both. Had a small glitch on compiling as it looks like MTP grabs some of RAM2, which I use as a secondary buffer when logging. I just reduced my buffer size a bit and it compiled and ran. I only have a class 1 SD...

Thanks Joe, Looks real straightforward. I was totally misunderstanding that SDFat was the best to use. I’ll try it out. Today I just loaded MTP after each run to get the data file. Clumsy, but so much better than moving the SD card.

Ok, so (and sorry for my naivety), in general, I should be using SD instead of SDfat?

I appreciate the feedback, thanks! I was thinking, 'too bad' in that it doesn't integrate directly into my code. I'm probably out of touch on this. I based my logger on the 'bench.ino' example, as I need large files and fast SD writes (I'm logging at 18Mbytes/sec for an hour). That code did...

Ah, ok., thanks Paul. Too bad. My backup plan was to just read the file and send it over USB-serial and capture that to a file. Not elegant , but functional. In any case, kudos for all the clever additions to Teensyduino. It’s humbling when I explore the core and library code.

Oh, this is cool. I got the example running, but I also need a serial USB interface. I wasn't sure they could co-exist, but if I do: void loop() { MTP.loop(); // Perform media access when PC wants access if( Serial.available()) { Serial.read(); Serial.println("hello"); } } it...

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 and a larger battery. I estimate that simply running...

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 criteria pretty much match the battery’s rated...

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 battery down past the linear regulator drop out...

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.

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 1.11. Current consumption dropped slightly to...

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.

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. At first I figured it was due to other components I...

I'm trying to have it do nothing else during data collection, but that's a good idea to keep in mind.

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 everything I have learned.

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 concept. Here is when it didn't work - 0 is my...

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 clock. But it doesn't latch the data until it is in...

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.

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 no go. - and I added a note in the code about...

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 good, which it ought to be, is to have the FPGA do...

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 get the ~40nsecs value. I should test again and...

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 you turn off USE_PROBE and jumper pin 0 to pin 1...

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 be wrong - ISR Here is the crux of the code. I do...

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 are from those block erases. I think I'll put in a...

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 enough: Delkin UHS-II 256GB V90 18MB/sec 30...

I believe so! Now I just need to see if the data I'm storing is right.

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 18 Latency (usecs) 115,078 32,733 139,088 35,201

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 after sync() rbMaxUsed = 239104 avg write us...

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

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. That produced the working chart. The odd thing is...

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 interesting that the buffer usage is much...

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 most recent, but that's the SDFat I had trouble...

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.

I'm using: https://github.com/greiman/SdFat Should I be using something else?

"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 that library. Then , looking at the verbose...

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 output below: Something is weird. Feb 9 2026...

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.

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 fully format a drive (takes an hour), and it's...

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 store metadata , then just did sector writes for...

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.

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 data is being stored during that time, which...

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 latency speed,max,min,avg KB/Sec,usec,usec,usec...

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.

Oops - I should have expanded that. It’s 4.5 mega-samples per second with each sample being 4 bytes- so 18 Mbytes/sec.

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 even short runs may not be immune.

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.

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 overrun. My initial idea is to have the processor...