USB on PIC uPs

For stand-alone microprocessors

USB on PIC uPs

Postby Doug Coulter » Wed Jun 22, 2011 9:59 am

I just got the USB dev kit from CCS and got things fired up. I got the bare board, no cables or tutorial this time. I found an example that moves data between a USB serial emulator and the PICs normal rs-232 to start with in the regular compiler distribution, made a project by copying this and all the include files to their own project directory, built it, and bam, it seems to work at least to the point of the PC seeing it, and recognizing the USB dev board as a serial port. I have a few glitches on the dev machine I'm using, so will have to drop back a little and fix that stuff up better.

Just to make it more complex (well....to have an excuse to use this fine machine more) I'm doing this right now on an 8 core i9 series with 32 gigs of ram (and a SSD drive (plus a tb of other drives) and 192 core nvidia gpu, man this thing screams!), running ubuntu 10.04 64 bit, with windows xp (32) running in virtual box for the ide and programmer. I might have screwed up adding another available processor core to the windows install post-install, as windows goes nuts trying to find "driver software" for a simple usb-serial dongle, and really doesn't have a clue about the new USB serial port the pic dev board makes (though linux sees it fine!).

Interesting that now it's windows that has all the issues of non support of odd hardware, eh? Or most of them. I got an off-brand PCI "real" serial port board that seems flakey in that machine, so I've got to fix up all that comm issue stuff before it's worth proceeding, or move to this machine or another for this job.

The goal of this project is to integrate the USB stuff into my "standard" opsys that has all the other nice features, and create a boilerplate project to add other things to down the road.

Probably the first specific project will be something like the "multigeiger" thing we've done already, simplified somewhat, to use as the base of our "standard counter" for activations. We might add some a/d data aq to this like we did there to grab things like power supply or pressure data during a run along with counts. The really nice thing about this USB is that all machines and opsys can handle it (my wierd windows problem notwithstanding, it's probably a cockpit type of error there), and it provides power to the device if it doesn't require tons. I've spent so much time building power supplies one after another for things I'm getting pretty sick of doing it, and this just makes that go away altogether -- and makes for a smaller, cheaper product too, bonus.

While just counting, measuring, and reporting some a/d results sounds trivial, it's actually not if you want real accuracy. For example, in counting -- what if a count comes in while I'm reading the counter? Have all the carries rippled yet? What if a count comes in while I'm resetting the counter after reading it? I'll be pulling out some tricks to handle that kind of thing -- resync to a random signal is still pretty much an unsolved problem in general -- but you can mess up only a little or a lot.

A/D inputs have issues too. In multigeiger, we took samples at about 30hz, and reported a sum of them for each channel once a second (if you add 30 samples, you get some more bits of effective resolution). If our sampled signal has any non-random noise on it that's under sampled, say 60hz -- we can see a huge long, slow sinusoidal drift as that "beats" with our fixed sample rate. But we could do a median smooth....and so on. there's more to this "simple" stuff than meets the eye if you want it "right" and of course I do.


One issue that's going to take some work is mapping our farm of USB-pic things to known places so PC software can deal with it in some automatic form. An issue linux and windows both seem to have is a more or less random assignment of a given USB-serial thing to a com port or tty number - the mapping seems to change on every boot and every time you plug something in or out.
In other words, unplugging something that was mapped to com3 and plugging it back in might make it com5 (while 3 is still there but gives errors if you talk to it) We could easily have a query/response thing on our own hardware to let it self-identify on a sweep of com ports, but -- whatever we use as a query might also screw up other USB devices that look like serial ports, maybe even dangerously -one of the things here is a USB driven arb waveform generator driving a 1.5kw amp -- you don't want to mess with that one. So it looks like digging into opsys innards to find a way to map com ports to USB vendor/serial number id's as a side issue. What a PITA, but if it was easy, anyone could do it and there'd be no money in it.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: USB on PIC uPs

Postby Joe Jarski » Wed Jun 22, 2011 11:26 pm

Dang, that didn't take long! Sounds like you're making pretty good progress on the USB interface. That should be a nice addition for the standard counter.
User avatar
Joe Jarski
 
Posts: 231
Joined: Thu Sep 16, 2010 8:37 pm
Location: SouthEast Michigan

Re: USB on PIC uPs

Postby Doug Coulter » Thu Jun 23, 2011 11:27 am

At this point the main issue is getting the dev PC set up right, then things should go quick. I plan to base a number of things off this -- USB is the new serial port (but faster), and has this big advantage of providing some power to the device, so there goes all that power supply building in the products (and the cost and size that go with that). USB will easily provide enough power to run a CCFL HV supply for the counter, for example. We can even use the PWM output of the pic to make a switcher for regulating that. Those CCFLs will run down to about 1 volt...so with the right volt multiplier on one, no sweat for this. We can even close the loop using a resistive divider to an A/D input if desired. For the Russian geiger tubes, I kind of doubt that will be necessary, though.
Geigers just ain't that picky -- phototubes are, though (and they draw current all the time, too - it can add up on power requirements if you're not careful).

But at least it's at the point where every machine I've plugged it into "sees" it correctly. That's a fairly big deal, as the USB protocol ain't trivial, and evidently their sample code gets it right. I may not even have to learn the details of that fancy built in hardware. Whew!
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: USB on PIC uPs

Postby Doug Coulter » Sat Jun 25, 2011 5:44 pm

Ok, some progress on this, but not so much on the PIC side. The issue I had was with my new dev machine, which doesn't have serial ports per se, just a buncha USB ports on which you can hang this, and serial<>USB dongles. It seems Ubuntu 10.04 64 bit just doesn't work with a pci serial card -- tried several, theres a lot of complaints about this on the 'net, and no answers that fix that.

FWIW, the example code from CCS just worked perfectly on the first burn...the main challenge there will be integrating it with other, more useful code and an opsys. Evidently, however, the compiler has noticed they do some interrupt-unsafe things, and gives warnings that it's inserted some interrupt disabling around them, which could really mess up my opsys and anything else that needs real time fast interrupt response -- so it might actually need major rework -- we'll just have to see.

The problem is this. At boot, if you're got a couple of those dongles plugged in, you can fairly well count on them being, say, /dev/ttyUSB0 and /dev/ttyUSB1. Until you sneeze, plug anything in or out (on either the usb or serial side) and so on. Then they get re-assigned to something else, leaving USB0 and 1 still there, but not working, which of course locks up the terminal programs -- I think I could eat some bits and sneeze a better system than this silly crap. After spending a couple days searching the 'net and looking in /proc as well as /dev and trying things and booting over and over (lucky this machine boots fast) I think I'm finally onto something I can do to fix this serious problem -- no point having the PIC work if the thing it's communicating with is flakey, so that became priority one. Once I really get it going and going right -- it takes creating some specific rules in a particular file in an obscure place -- already knowing intimate details of manufacturer names, ID's, serial numbers and so forth for each device, you can have them just go to a uniform place -- as in "/dev/DougsGeiger" no matter what the boot order or hot plug order is. A PITA but a one time one. It only took a few whole days to find an answer -- not very good, only a couple weeks faster than Microsoft support would have taken (and there's so far NO solution known to the same thing over in Windows -- you just have to never jiggle anything, and always have all USB devices powered up at boot).

For now, I'll stick some links etc here so I don't lose them myself while attempting to get other things done and that rules file made correctly for all my usb dongles.
USBStuff.txt
Some printouts from diagnostic programs
(8.74 KiB) Downloaded 334 times

Screenshot.png
Screen demo


I'm doing it this way because I learned long ago that if you can't trust your test gear, all bets are off and until that's right, no point in proceeding -- you may as well take up a kinder hobby, like self-flagellation. And I need this anyway, for this and other things that depend on USB for data logging -- we need the PC program side to be rock-solid-stable or there's not much reason to proceed -- and I refuse to write code that keeps looking around for a moving target data source.

And yes, it's that bad. You can have a terminal attached to ttyUSB0, then hotplug some other USBtty -- and ttyUSB0 is now some other random number, even though absolutely nothing changed on it by itself... that's a bug in Linux most surely. Windows at least doesn't have that one -- but new hotplugs, come out as the next com port. If in windows you unplug com3, and plug it back in, it will become some other random com number, however -- more or less the same set of issues. Both seem to keep the original assignment/mapping around, but dead, for some odd reason, so when something gets plugged back in, it can't go there and has to go to someplace not yet used.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: USB on PIC uPs

Postby Doug Coulter » Sun Jun 26, 2011 9:23 pm

Some progress on the PIC part of things. I decided to not finish solving that random assignment issue, but I did get a little closer.

At any rate, time to put in some PIC code.
I put nearly all of it into a separate file, called opsysutils.h, to keep it separate from their USB example code. I'm slowing cleaning up *their code* to get rid of a bunch of confusing stuff for a ton of other processors and even external USB hardware -- don't need it here, and it makes the live code hard to find. I did this by copying all the example files and includes to the local project directory, and changing all the #include statements to remove the <> and substitute "" around the filenames, so it would look locally first. Then made sure the IDE was also using those copies, so I don't bork the originals -- you never know what you might need later.

I added code for timer1 to interrupt at 10ms intervals, based off the main cpu clock, and keep track of hours, minutes, seconds, and tens of milliseconds since power up. This is in three parts. One in my opsysinit() function, where I set the timer up to count the cpu clock after a prescale, interrupt on overflow, and set a value in there so it overflows in 10ms instead of something else.
that looks like this:

Code: Select all
// timer one counts the cpu system clock, to interrupt at 100hz (10ms)
setup_timer_1(T1_INTERNAL | T1_DIV_BY_8); // 1.5 mhz with 12 mhz cycle rate
set_timer1(65536-15000); // set to overflow at 100 hz
enable_interrupts(INT_TIMER1);


Not too bad. Global interrupts are already enabled by their code, and mine too in case something in theirs changes. When this overflows, it gets here:

Code: Select all
///////////////////////////////////////
#INT_TIMER1
void intTimer1()
{
set_timer1(65536-15000); // get ready for next time, count for 10ms
secdiv++; // count 10 ms times till a second's worth
if (secdiv >= 100)
  {
   secdiv = 0; // ready for next second's counting
   secflag = TRUE; // tell background about the new second
  }
// oneshots code here...count down any non-zero oneshots till they are zero
// at 10 ms per count.  You can set these in the background, then check for
// done once per main loop, and your timing delay is what you set.  This way
// you don't have to sit in a spin loop and wait, so other things can be
// run while a oneshot counts down
for (ii=0;ii<NO_ONESHOTS;ii++)
{
  if (oneshots[ii]) oneshots[ii]--; // count down any non-zero ones
}
}


Due to the prescale, timer1 is counting at 1.5 mhz (the clocks in this thing are deeply weird -- a 20 mhz xtal that runs the USB at 96 mhz and the cpu at 12). So every time it overflows we need to reset it with a number that will make it overflow when we want -- in this case 10ms is reasonable. The nature of the computation in the statement (done at compile time, not run time) shows how that works to get 100 hz.

So, this sets a flag (secflag) on the second, counting up a counter (secdiv) to know when. That lets the code in the main loop know when a second has elapsed.
The main loop checks this flag and calls TimeMachine(), which is a cool name for a dumb function that knows how to count seconds and minutes and hours since startup.

I am also counting down members of the array "oneshots". This is an opsys service for the main code. If you set one of these to some non-zero number, it will count to zero at 10ms per count.
The idea is that some state machine called in the main loop could wait without wasting a lot of cycles, by checking a one shot it had set for zero, and just returning to the main loop if it's not zero yet.
This is far better than sitting there waiting -- nothing else can run if you do that. But it only takes a few cycles to check and return if you're just waiting this way. Not using that feature yet, but we always wind up needing it so I went ahead and added it now.

TimeMachine looks like this:

Code: Select all
///////////////////////////////////////
// Call this once a second from main loop.  Clears the seconds flag and
// does the mundane conversions for time in seconds to clock time (since start)
void TimeMachine()
{
if (++seconds >= 60) // the use of >= makes this work even without good init
{
  seconds = 0; // new minute
  if (++minutes >= 60) // >= belt AND suspenders
  {
   minutes = 0; // new hour
   hours++; // so do that increment too
  } // end if minutes overflow
}// end if seconds overflow
// we just hope hours don't overflow in a 16 bit int -- that's a long run
secflag = FALSE; // clear interrupt flag
}


Like I said, mundane. The only trick here is using "greater than or equal" to trip the seconds and minutes rollover. No point not being safe, and it compiles down to the same amount of asm. No matter what those number are going in, this recovers from error as best it can.

So, up in the main loop, we call our stuff along with the original example stuff.
Before this, we've called various init routines to get the hardware going, and the light in the right state, and so on. Once we fall into this loop, that's what we run "forever", along with interrupt service routines (ISRs). We just call tasks in turn, and do a little each roundy round. I wouldn't have put the usb<>serial port stuff inline here, but in another function so the main loop would be shorter and sweeter.


Code: Select all
void main(void)
{
   char c;   
//   HW_INIT(); // not defined for some cpus
   opsysinit(); // Clab's stuff - setup timers, counters, interrupts, memory
   LED_OFF(LED1);
   LED_OFF(LED2);
   LED_OFF(LED3);
   uart_printf("\r\nC-lab Standard Counter\r\n");
  #if defined(__PCH__)
   uart_printf("PCH: v");
   uart_printf(__PCH__);
  #endif
   uart_printf("\r\n");
   usb_init_cs(); // initialize the USB library

/*************************************************************************
// we just go around this loop till power fails.  Call each task in turn,
// and design the tasks to return quick -- no blocking or the whole thing
// will hang.  Check for work, do a little, return, you'll get called
// again soon if everyone follows the rules.
*/////////////////////////////////////////////////////////////////////////
   while (TRUE)
   {
      usb_task(); // attend to any USB activity
      usb_debug_task(); // do the leds showing USB connection status
// adding my stuff to this forever loop
      if (secflag)
      {
      TimeMachine(); // keep running time clock up to speed
// do anthing else needing 1/second timing here
      uart_printf("\n%Ld:%02u:%02u",hours,minutes,seconds);
// get the full count     
     TotalCount = make32(CountsHigh,get_timer0()); //@@@ not interrupt-safe
      uart_printf("\tCounts:%Ld",TotalCount);
      } // end if seconds flag

      if (uart_kbhit()) // pass stuff between the 232 and usb ports
      {
         c=uart_getc();// the if's below make this "windows safe" /r/n
         if (c=='\n') {usb_cdc_putc('\r'); usb_cdc_putc('\n');}
         else if (c=='\r') {usb_cdc_putc('\r'); usb_cdc_putc('\n');}
         else if (c=='!') {uart_printf(usb_cdc_putc,"HELLO-WORLD-DONE");}
         else {usb_cdc_putc(c);}
      }
      if (usb_cdc_kbhit())
      { // handle dumb windows that needs two chars for a new line
         c=usb_cdc_getc();
         if (c=='\n') {uart_putc('\r'); uart_putc('\n');}
         else if (c=='\r') {uart_putc('\r'); uart_putc('\n');}
         else {uart_putc(c);}
      }
   } // end while true
} // end main


This has some code that is needed for windows -- there's this problem there. Windows needs /r/n for a newline. Mac needs /n/r, and linux will take either or both. I'm not sure how much fiddling I'll do on that, since I run linux..and /n gets it all done there (this is the character the return key produces anyway).

The above code, along with the code I added to setup timer0 to be the main counter of geigers, does the following:

Once per second, run time and counts (up to 32 bits worth) are printed on the uart.
Anything coming in either the uart or usb gets passed to the other one. If a ! is typed into the uart, it triggers a special HELLO WOLRD message out of the USB port. Maybe they knew which was which was going to get confusing when these dumb pc opsys reassign ports everytime the thing is reset or programmed.

At any rate, duh, I could ship this as done, but of course I have some other tasks. I need some PC software to shove this into a database, I'd like to have the PIC compute some more stuff, maybe get some a/d channels and so on -- CPM and CPS based on the current and previous 10 counts, nice stuff like that. And I've not yet solved the random port assignment issue yet on any pc opsys and that's just dumb. Linux has a way to add rules to udev files to map known vendor/id to known names, but while it does create a file in /dev, gtkterm reports "bad ioctl" on it, so a little more to figure out.

At any rate, I can type to myself on another terminal either way to hearts content, while one of them is printing lines showing time and counts. The rest is sugar coating.

Screenshot-1.png
fooling around


Here's what one of my linux screens looks like after typing into the uart and pressing the "count" button. The lower terminal is coming out of USB. I could have this streaming out either or both at this point. Just a matter of changing a destination in a call.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: USB on PIC uPs

Postby Doug Coulter » Mon Jun 27, 2011 5:38 pm

Ok, this is getting to the point of needing to define the output format for the std counter. If anyone is going to want one, and has a suggestion, now's the time.

At boot, this puts out a text banner, and some debug about the USB stuff that I can remove if it's desirable. The protoboard version also outputs all this on plain jane rs232, but since that's more space and parts, we may not keep that one around. It's going to be USB powered at any rate, since that's plenty for the HV for the geiger tube, and batteries get marginal without a fancy switching input power supply for the CCFL otherwise. You need a computer for readout anyway.

I plan a line per second of ascii (human readable) output, no need for any input to this (at present) - parameters to be fixed, after all, it's just a counter.

First entry on line to be HH:MM:SS with hours going up to 65535 -- that's a long run. All the time is since power up and driven off the cpu clock - not as accurate as your watch, but decent.

Right now, all I have is total counts next. That's going to be the last thing on a line if it survives at all, it's just there for debug now (and later, for detecting rollover errors for correction in PC software, perhaps).

I'm thinking counts this second, and counts for the last 10 seconds as the "valuable ones" here (with the 10 sec count updating every second). In my other stuff like this, I normalize the counts to CPM by multiplying by either 6 or 60 depending on which interval I'm scaling. I haven't done the rolling 10 sec in the past, but it seems nicer than fixed 10 sec chunks for a lot of things.
I'll entertain requests for a count reset button if people think they need that one, but it adds size and cost and this thing won't have a lot of "state" anyway - just the 10 sec rolling count.

The real question is one I'm not real qualified to answer myself as I plan to write my own code to take this data apart and shove it into a database. It is: What should I use between the numbers for those who use spreadsheets, or whatever it is you use? I plan on having labels before each number too. Time might be preceeded by T:, and other numbers perhaps by C1:, C10: or similar, as that's nice on the human eyes. But using colons both as time and label separators might give some excel user heartburn. Commas? Spaces? Anyone have input on this?
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: USB on PIC uPs

Postby Joe Jarski » Mon Jun 27, 2011 7:10 pm

I don't know if this is the best way to go, but I've extracted CAD data quite often that is separated by several spaces... like 7. I'm not sure if there is any significance to the number of spaces, but it's pretty easy to import into excel or Open Office in that format. I haven't tried other types of separators, so there may be something better.
User avatar
Joe Jarski
 
Posts: 231
Joined: Thu Sep 16, 2010 8:37 pm
Location: SouthEast Michigan

Re: USB on PIC uPs

Postby Doug Coulter » Mon Jun 27, 2011 7:59 pm

I hear csv is common (comma separated values) and that a few things eat that naturally (MySQL for one). "Whitespace" is also real workable and easy to parse, whether spaces or tabs. Like I said -- I'll do my own code for that (and make it available to all of course) but for those who don't work like that and stuff everything into a spreadsheet or something else, it'd be nice to make it easy for them too. As far as I know, they don't make it easy to put in your own parsing code -- they read their native format, and maybe a couple of others, but I know diddly from spreadsheets myself, never used them. Actually, if excel and open office eat whitespace, that's the easiest for everything, since perl will also do that with the default "split" command and no arguments whatever -- it will just hand you an array of values from that, nice and simple and sweet.

I've been running this thing now for a few hours counting at 200khz and haven't managed to catch it in the act of making a rollover error....so at worst, they're not too common. But one reason to keep outputting total counts (along with the more immediate data) is that you can go back through it and easily detect and fix one of those. I could do it in the pic too, and might, but....I'm a big believer in raw data being available. That's just philosophy, but one widely held, because you just never know when a new insight will make it more valuable than "interpreted or smoothed" data.

The possible error you can have in this is that the 16 bit counter rolls over and you get the near zero result out of the counter, but without the high part having been incremented. Turning off interrupts while reading makes it worse, not better. Turning the counter off is worse too -- you lose counts. About the only way to handle that one is to look for a number that went down, when there's only one direction it can go when there aren't errors - up.

I'm hoping that hours up to 65535 and counts to 4 billion will be enough for any one run, but speak now or it's cast in stone soon. This job won't run this PIC out of any resource or even close. It's tempting to think of features to add (a/d for example), but getting too fancy might kinda mess it up for the original intended purpose of just being a standard counter for the lab. I need to keep the line length to under 64 for one thing, or do much fancier output code to handle more than one buffer per line.

And now I gotta figure things like packaging etc. Should be pretty simple if Apple doesn't sue me for using a rectangular box (as they are Samsung). I want to have the pancake geiger facing up, and sticking out of the top a little so the aluminum beta shield still fits, and so you can just lay activation samples right on the tube as I do here. It eliminates some sources of errors to have it touching the sensor frame -- no spacing variations and low energy losses in the intervening air.

In fact, I may ditch the idea of porting this over to the cheaper pic chip (there are issues with that not having as much dedicated USB "endpoint" memory in the hardware) and just dupe this, even though I did buy those other chips already (they're cheap, I'll use them for something else anyway). The big guys like on this dev kit board aren't bad - $8 in onesies. In either package (44 p flatpack, or 40 dip). I'm leaning toward dip at the moment as with a socket they can be reprogrammed without an extra connector for that -- and exchanged through the mail...I'll have to mull that over along with any input I get before doing the final design I guess.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: USB on PIC uPs

Postby Doug Coulter » Mon Jun 27, 2011 9:21 pm

Just a little eye candy. Found and fixed minor bugs and got a nice screenshot. Forgot to use the right thing in printf for unsigned, and that the pic timer0 divides by two unless you tell it otherwise. It'd been counting at 2 mhz more or less in this picture -- it'll go faster I think, but that should do it for almost anything we'll want the basic thing for.
Screenshot-8.png
Screenshot
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Re: USB on PIC uPs

Postby Doug Coulter » Tue Jun 28, 2011 1:09 pm

A little more eye candy. Here's the whole thing, working. Of course there's that little detail of changing this from a proto setup to a real thing we can ship out. But this is really all it takes.
I discovered that if I run the CCFL off the 5v, I can just use a half wave rectifier and no doubling. To get the volts just right, I used a 47 ohm resistor in series with it (which has a side benefit of protecting things from over-current). The signal processing couldn't be more trivial -- 47 pf coupling cap (not critical), a 1 meg feed from the HV (about 415v), and a one meg in series to the pic counter input, with a 47k pullup to 5v. Done. I will add 1n4148 diodes across the pic input to gnd and +5v "just in case" but really -- through a 1 meg resistor we're not going to be pushing lighting bolts into it anyway. So, some board layout, and a box, a little more code, and we're done with this one. With a different HV PS and a preamp, this would run fine on the B10 tubes etc too.
StdCtrProto.jpg
In all it's ugly kludgey glory


This is counting 22.7 cpm on my upstairs bench on mid-day background. It's pretty quiet up here today rad wise (and on the second floor so we don't see the radon stuff from the ground). This would imply somewhat less sensitivity than my other pancake counter, roughly proportional to the size. It will do fine for activations etc, and I'll get a real good cross calibration soon off a standard sample.
Posting as just me, not as the forum owner. Everything I say is "in my opinion" and YMMV -- which should go for everyone without saying.
User avatar
Doug Coulter
 
Posts: 3515
Joined: Wed Jul 14, 2010 7:05 pm
Location: Floyd county, VA, USA

Next

Return to Embedded software

Who is online

Users browsing this forum: No registered users and 1 guest