ijourneaux:
I think I have all of the parts. The hall sensor is much smaller in size than I was expecting . That is a good thing but I am going to have to figure out how to solder leads to the sensor.
And I better put aside the "real" coding and get started on the testbed coding.
So just to check out the touch sensor, how about using the green LED to indicate touched ?
My thinking re: the Hall sensor is to record (probably to EEPROM) the readings once they get above a threshold. That limits us to ~1000 readings, and only then if I reduce the 10 bits to 8 bits. IIRC I have some code I wrote for a kontiki along these lines. The idea being that you’d run the testbed past the hogline and then connect a PC to the Micro and read out the data. Wash, rinse, repeat at differing speeds and hoglines. That way we get a sampling of the magnetic field strengths vs hoglines and distance from hogline (and field polarity). It would take a few runs to tweak the settings (sample rate, threshold to start recording, which 8 bits to keep) to be optimal. I could have the red LED come on for fields stronger than some threshold once tweaked.
A much simpler task (for me) would just to “print” the readings to the serial port and for you to have a PC (constantly) attached and recording the serial monitor to a file. You wouldn’t “throw” the testbed past a hogline so much as position it at some distance from the hogline and see what you get. Given I can do this tonight and it’ll give you a way to check out that the Hall sensor is working w/a test magnet … I’ll do this first.
BTW never have the Micro running off the battery and plugged into the PC. THE BATTERY VOLTAGE WILL FIGHT THE USB 5V AND LIKELY SMOKE SOMETHING.
Would you recommend soldering headers to the pro micro?
My first thought is no. Headers are useful if you're going to use jumpers to connect to them, especially if the connections are to be changed often. I don't see that happening.
OK here’s the simple code as mentioned above. Green LED for touch sensor, red for Hall sensor > threshold. Set the serial monitor for 9600 baud and follow the instructions. I’ve tested the code as well as I can ATM. It seems to work as advertised.
//very 1st cut at Curling testbed code
//put includes here
//define constants used
const int capPin = 2; //pin for cap sensor input
const int hallPin = A0; //pin for Hall sensor input
const int grnLEDpin = 5; //pin for green LED output
const int redLEDpin = 6; //pin for red LED output
const int magThrsh = 100; //magnitude of Hall reading needed to trip red LED
const unsigned long looptime = 500; //loop time
//define variables used
int magOffset = 0; //offset from Hall sensor
int magReading = 0; //magnitude of raw Hall reading with offset removed
float magSum = 0; //sum used in computing offset
void setup(){
Serial.begin(9600);
pinMode(capPin, INPUT_PULLUP);
pinMode(redLEDpin, OUTPUT);
pinMode(grnLEDpin, OUTPUT);
digitalWrite(redLEDpin, LOW);
digitalWrite(grnLEDpin, LOW);
delay(3000);
//send a message re calibration
Serial.println("Place the sensor down flat, going to perform offset calibration");
delay(3000); //wait 3 secs
Serial.println("Performing offset calibration");
//take 20 A/D readings spaced 1 msec apart
for(int i = 0; i < 20; i++){
magSum += analogRead(hallPin);
delay(1);
}
//now compute average
magOffset = int(magSum/20.0);
Serial.print("Done. Offset is ");
Serial.println(magOffset);
Serial.println("Now place testbed near magnet to be measured");
}
void loop(){
Serial.print("raw Hall reading is ");
magReading = analogRead(hallPin);
Serial.print(magReading);
magReading = abs(magReading - magOffset);
Serial.print(" Feild strength is ");
Serial.println(magReading);
//turn on off red LED
if(magReading > magThrsh){
digitalWrite(redLEDpin, HIGH);
}
else{
digitalWrite(redLEDpin, LOW);
}
//turn on off green LED
digitalWrite(grnLEDpin, digitalRead(capPin));
delay(looptime);
}
While it might have been obvious to you, I just noticed a wiring error in the prior diagram. Instead of having power wired to Vcc of the Pro Micro, I was off by a pin and had it going to A3. Who needs bifocals ? :mrgreen: So a corrected diagram is below. It does give me a reason to explain the odd power scheme though.
Normally power comes into the Pro Micro via the USB plug or the “raw” pin/hole. They are separated by a diode and both go into a 3.3v regulator. The output of that regulator then goes to the 32U4 MCU and to the pin/hole labelled Vcc. So when the testbed has no battery (or SW1 is open) and the Pro Micro is plugged into the USB cable, 5v comes in and every thing runs off the regulated 3.3v.
When not plugged in, the battery is connected directly to everything and “backfeeds” the regulator. This shouldn’t harm it (though it’s a power waster), indeed on the 5v Pro Micros the USB 5v is similarly backfed into it’s 5v regulator. Now a fully charged CR123 is like most rechargeable Li batts, perhaps at 4.2v right off the charger, falling to 3.7 and staying btw that and ~3.1v for it’s usable life. So that’s a bit higher voltage (to start) than the desired 3.6v but it should be OK. All the parts list 5.5v as their max input voltage. The gain and offset of the Hall sensor will vary with supply voltage, but that’s OK too. The real code will also do an offset calibration on powerup. And the threshold to detect the hogline will have enough slack to guarantee detection at “low” battery voltage.
At some point when this is all working, we’ll need to embark on a power reduction journey and at that time you’ll need to (at least) desolder and lift the output pin of the regulator off it’s pad so that it’s current draw isn’t inflating the true current needed.
I found my prior (tiki) code and it’s starting to come back to come back to me (re: storing data in EEPROM). So now we need to decide what’s needed, initially, for data. My thinking is to store perhaps 600 data points (at a byte/pt) in a continuously running ring. Then when a threshold is crossed some X times consecutively, the code will store the next 300 samples and stop. Ideally this will give us 300 samples before the hogline and 300 after. I’d like to see what the field looks like for 1 ft before and 1 ft after and that’s ~ 600 mm of travel. So 600 points yields a spacing of 1mm btw each point. No doubt more than needed in both spatial resolution and extent, but it’s easy to reduce that after we see what we see in “fine” detail.
Since the Micro doesn’t “know” distance but rather time, I have to assume a typical stone speed. From the wiki I might guess 7.5 ft/sec and so it takes ~ 267 msec to go the 2’ above. 600 samples in 267 msecs means ~445 usec btw samples. That’s do-able in my experience. And if the speed is a bit faster or slower, no big deal.
I expect after a some runs of the above we could reduce the number of data points saved and thereby get multiple runs before having to connect up a PC and download the data. I can also envision a different program that “surveys” a sheet, storing peak values > noise and their times, to try to get some sort of handle on the false alarms.
Thoughts ?
That seems to be quite reasonable. I need to stop by radioshack to pick up some flexible thin wire for the hall sensor. What have is too stiff and thick to attach to the 1304. The rest of the wiring is straight forward. I hope to have it built by this weekend.
It doesn’t look pretty but I have the device assembled. Unforunately I can’t get the Pro Micro to be recognized in Windows so I can download the sketch. The device shows up as a USB IO board in Other Devices in Device Manager. Trying to troubleshoot as we speak.
The Device ID is listed in the Micropro.inf file but when I select it II get an error
“Third Party INF does not contain digital signature information”
I am not sur ehow critical i=this actuallyy is or if it is a read herring
Changed computers and the problem seemed to be resolved. Was able to download the sketch but it did not work. I think I selected the wrong controller. Now I can’t get the Pro Micro to show up again when I connect it to the computer.
I found the webpage describing how to restore a “bricked” pro micro but have not had any luck getting it into a mode where I can reprogram.
Right now when I plug the Pro Micro into the USB port on my computer, don’t see it show up in device manager.If I reset the Pro micro by shorting out the reset to gnd pins, I can see the devices shuffle in Device Manager but the Pro Micro never seems to show up as a valid device. I am assuming it should show up in the com port section.
Ian
With appropriate shorting of the rst pin, I can get the Pro Micro to show up but the 8sec you get when you click on the short the reset line twice is not sufficient to both select the com port in the IDE and upload the sketch.
Not sure what to tell you. I have a 32U4 device but it’s a “true” Arduino Micro and si has the old bootloader. When I plug it into my Win7 64bit PC, Device Manager shows it as “Arduino bootloader” on COM4. After 8 secs it switches to “Arduino Micro” on COM5. Serial comm goes through COM5 as expected. My selected board under Tools in the Arduino IDE is, as expected, Arduino Micro. I also see Device Manager shows another “HID Keyboard Device” as well as a new Human Interface Device, “USB Input Device”.
I had thought the “new” INF file, mentioned in the post linked above, would solved any problems. I doubt the Arduino is truly bricked. It’s Windows (? Win7, 8, 8.1, Linux, Mac OS ?) that’s confused.
ijourneaux:
With appropriate shorting of the rst pin, I can get the Pro Micro to show up but the 8sec you get when you click on the short the reset line twice is not sufficient to both select the com port in the IDE and upload the sketch.
I've seen the same problem reported and yet there must be a "fix", either at SFE tech support or in the larger Arduino forum.
In case you missed this page …
https://learn.sparkfun.com/tutorials/pr … ng-and-faq
On Pro Micro’s, or other devices which don’t have a reset button, you can either use a wire to quickly short ‘RST’ to ‘GND’ twice, or wire up a temporary reset button. While the Pro Micro is in the bootloader change the ‘Tools > Serial Port’ menu to the bootloader COM port. Quick! You’ve only got eight seconds. On Windows, the bootloader’s COM port number is usually one number higher than the Pro Micro’s regular port number.
Re the above: could you “guess” at the COM port number in the IDE ahead of time ? Funny how my Micro has it’s BL’er COM port # one less.
I agree that the Arduino is not truly bricked just can’t access it. I must have tried for an hour to reset the Pro Micro and upload a sketch and could not get the sketch successfully uploaded.
When you reset (2 resets quickly) the Pro Micro, it briefly shows up in device manager as a SparkFun … device on Com9. If I time it correctly, com9 show up as a valid port in the Arduino IDE. If I do nothing, the device changes to an “unrecognized USB device”.
It appears from the different pages I have read that I may need to restore the boot loader. I have several Arduino Uno’s so I should be able to use it to restore the bootloader on the Pro Micro. Now I just need to get the correct bootloader.
Mean while, I ordered a second Pro Micro so we con continue moving forward on the sensor handle project.
I’ve coded, but not tested, the v2 testbed program. The one that tries to detect the hogline and store pre-, during- and post-hogline crossing data to EEPROM. If I can find my missing 10k pot or analog joystick I can do the testing (such as I can) in a day. Let me know when you need it. Until then you can use the posted v1 code to verify basic functionality and sensor performance.
Wish I knew more about fixing your ‘bricked’ MCU.
I haven’t forgotten about you. My new Pro Micro came in on Saturday. I am hoping to make another pass at it over the next couple of days.
After several attempts to reburn the bootloader, it appears that the first Pro MIcro is really dead. I can’t get any response out of it now.
Ok. I got the new Pro Micro wired up. Mydrpping resistors are alittle to large so the green LED (capacitance sensor) just barely lights up but it does light up.
I was not able to get the the hall sensor LED to work. I see in the sketch that you have a threshold defined currently set at 100 and an Offset.
Is there any way to see the value being read by the Arduino. I am questioning if the hall sensor is working as I found it very difficult to solder.
Given the difficulty I am having working with the smd A1304 Hall effect sensor, would either of these work for this project
Digi-Key part 480-2006-ND
Digi-Key part 480-3597-ND
They seem to be 2.7-6.5V parts with linear ratiometric output parts.
ijourneaux:
Is there any way to see the value being read by the Arduino.
Yes, that was intend from the beginning. You need to have the ProMicro plugged into your PC w/the serial monitor (or some other terminal emulator program, Hyperterminal, Realterm, Terraterm, etc) set for 8N1 and 9600 baud on the proper COM port. After the ProMicro boots it'll send a message telling you to place the testbed flat (on the ice) to do an offset calibration. The reason is that the sensor will output a DC voltage about halfway btw 0 and it's supply voltage w/o any magnetic field present. This, plus any added offset due to Earth's mag field, needs to be known so as to detect deviation from is, presumably due the hogline magnet.
You really don’t have to place the testbed flat, I expect that the Earth’s mag field will produce only a very small effect. So 3 secs after the message the code will take 20 readings and send out the result. Even if you miss the start-up cal and message the code runs in a loop reporting the raw reading and deviation from the offset half sec, independent of the threshold.
The threshold, which I agree is probably waaay too high, only controls the red LED. Given I want/hope to reduce the 10 bit A/D reading to 8 bits w/o losing info (to ease storing it in EEPROM), the deviation should be < 127 counts. Perhaps the threshold should be 25 ? In any case I’m counting on you to hookup your PC and get/record these numbers as they are sent. I want to know how much random noise there is (w/ no mag field) and what the reading is sitting over a typical hogline. The will allow me to tune the next testbed code.
ijourneaux:
Given the difficulty I am having working with the smd A1304 Hall effect sensor, would either of these work for this project
Digi-Key part 480-2006-ND
Digi-Key part 480-3597-ND
They seem to be 2.7-6.5V parts with linear ratiometric output parts.
Those could work, they're just less sensitive (1.4 mV/Gauss vs 4.0 mV/Gauss) than the other part. Heck, they might be preferable. I just can't say until you've measured a hogline's field strength. We're working in the dark re:this one point.
Whatever you get, get 2 or 3. They’re cheap compared to the S&H $s.
To hook the pro micro to capture the log data on the com port, I am assuming you hook it up via USB but with the battery removed?