First of all, this assumes you have a form in InfoPath (any version older than 2013, I haven't tested that one), and that you want to publish that form into a SharePoint site as a Content Type. This is advantageous to the site, because that form can be reused as much as you want in the Site Collection (although they work only so well in Content Type Hubs, the reason being the template XSN file crosses the Site Collection barrier, which is generally a no-no).
BUT: You need to be careful how you document your content type in the Description box in InfoPath. Here is where the Office team messed up: They don't do any encoding or sanitizing of the text in that box before sending it off to the Webs web service in SharePoint (Webs.asmx). As a result, any XML tags, or HTML tags, or hell, ANY stray double quotes (") or greater-than/less-than symbols (<) (>), will make their way into the call, and gum up the whole works.
The reason this fails is the call to the Webs.asmx service is SOAP, which is pure XML, and the description is sent as an Attribute, not as a text node value.
Here's the real rub, though: if you DO happen to have illegal characters in there, InfoPath won't error out. Instead it will successfully publish the form to the site, but then prompt for credentials over and over and over again for the web service. If you're foolish enough to continue clicking Ok you'll eventually lock out your AD account in the process. When you click Cancel, it will say "Creating the site content type failed." That's it. No help at all. What it should say, instead of prompting at all is "SOAP error" or "400: Bad Request" which is what is actually happening in the background.
What it took to find this little sucker was installing Fiddler on the local machine and watching the traffic going out to the website. I was seeing HTTP 400 errors when the web calls were being made, and in looking at the RAW SOAP XML request to the service, that's where I saw the Description attribute, and it was invalid, thanks to double quotes in my description.
I lost 4 hours to this error, and had to drag in a sys-admin to help me figure out Fiddler to see the raw data. I hope this helps someone else...
Friday, May 17, 2013
Friday, May 10, 2013
Friends don't let friends use RC4
And there are a myriad of reasons why. Despite its great speed and small footprint, its simplicity also leaves it wide open to faults and attacks. So it's no longer recommended for any new implementations, and existing implementations should stop using it.
But here's the rub. It was so widespread during the early days of many Internet and Wireless protocols (and is STILL used), you actually CAN'T get rid of it entirely, and you can't improve upon it without breaking compatibility with older systems.
This is probably the most frustrating aspect of ALL crypto-systems: Something that is great one day, can be (probably) broken in a short time frame (5-10 years or less), but is SO great, that it gets put into EVERYTHING before all hell breaks loose, and the industry as a whole is slow to adopt new tactics and algorithms, leaving the rest of us with "Swiss cheese security."
Take DES, as an example. It was developed a long time ago when computers were still HUGE, and desktop computing hadn't really happened yet. It was quickly broken as home computers became more and more powerful in the late 80's, and as cryptanalysts developed new techniques for getting algorithms to give up their secrets (quite literally) through careful bit manipulation and extensive comparison of inputs and outputs, it became clear that a new algorithm was needed.
In the move to get rid of DES, it was so prevalent, that the best anybody could do at the time (since DES was an adopted NIST FIPS standard) was to simply implement it 3 times in succession with a longer overall key (once forward, once backward, once again forward, each with a different, usually independent, piece of the overall key). Thus "Triple DES" or "3DES" was born. Hardly any new hardware required, and very little new software, just use what you have 3 times.
This was... ok... except it was later determined that the process of having the center transformation reversed caused some of the bits in the key to "not matter." Instead of 168 bits of security, you basically only get 112. Bummer.
And NIST calls it, effectively, 80. Double bummer.
And with modern hardware, a single DES key can be broken by brute-force in a matter of minutes or hours. Triple bummer. (see what I did there?)
Then came AES, which was chosen after a long competition held by NIST with some of the best crypto minds in the world (it was adopted in 2002 officially after an exhaustive process starting in 1997). It's only just now starting to show cracks (in 2011 or 2012, I can't find the original article, someone figured out that in the 256 bit version, the key expansion schedule had some peculiar behavior that COULD someday lead to an attack).
AES is now one of the most adopted algorithms in software*, because it's free, open source, and actually required for many US Government processes. (*I'm making an educated guess here based on my own experience.) It's even found its way into some Intel CPU architectures as a stand-alone Arithmetic Logic Unit (ALU), right alongside all the other key parts of the CPU. Try changing that out in all the PC's in the world if it were ever broken!
But I'm getting away from the plot...
RC4 was one of those algorithms that emerged and showed great promise due to its great speed and small memory footprint (less than 280 bytes in memory). It was so fast, in fact, that it was adopted when the first short-range, wireless connectivity standards were being implemented (remember 802.11a and WEP?). It does, however, still require a license (as of the time of writing this article) from RSA, the original developer.
The trouble is, by the time all the faults were discovered, 802.11a and all of its children were already in VERY widespread use. The idea of forcing manufactures and software vendors to change hundreds of thousands of devices (many of which had no way to "flash" new programs) was completely out of the question. New standards, which overcame SOME of the flaws, were later adopted (enter WPA, WPA2Personal/Enterprise), but the damage had already been done.
RC4 is dead! Long live RC4!
Yup, it's still out there, in use, in production, and it shouldn't be... but I digress.
One thing I will say, though, is that for quick-and-dirty encryption (read weak and probably easily cracked), its speed is largely unmatched. So even I dipped my toes in the water with a way to try and improve it, but I seriously doubt my way is any better than the last attempts.
But, if you need to use something small and lightweight... *wince* I can't recommend anything else that fits the same memory/code footprint *wince*. I would normally say use BlowFish, TwoFish, or even ThreeFish, but... *shrug* for this discussion, we're going "cheap"...
For starters, don't use the standard version in your final implementation (and not at all if you don't obtain a license from RSA; remember, this algorithm is still under their control). Do this instead:
DISCLAIMER: USE AT YOUR OWN RISK, AND ONLY AFTER OBTAINING KNOWLEDGE OF THE LOCAL LAWS AND REGULATIONS OF YOUR JURISDICTION. AUTHOR MAINTAINS NO WARRANTY OF ANY KIND NOR OF ANY SOUNDNESS, VIABILITY, SECURITY, OR TRUSTWORTHINESS OF THIS CONCEPT! READER IS CAUTIONED AGAINST USING STRANGE ALGORITHMS FROM STRANGERS WITHOUT PRIOR CONSENT OF AN ADULT. YOU ARE ON YOUR OWN, AND AUTHOR ACCEPTS NO RESPONSIBILITY FOR WHAT YOU DECIDE TO DO WITH YOUR LIFE.
Start with the standard version, just to build up the base, but remember that its flaws are numerous, and mostly surround the starting state, and the first 1000 bytes or so of output. From the standard, deviate with the following:
1. Input key is passed through [RIPEMD-160] hash first before the state is initialized.
(any decent hash will do, just stay away from MD5 and SHA-1; you don't need to go to
full SHA-512, or Skein, or Blake, or Keccak or anything like that, this is quick-
and-dirty after-all, right? Use all the bits that are output from the hash)
2. Initialization is increased from 1 pass through the state buffer to 3
(basically, increase from 256 key-based swaps to 768).
3. First 4096 bytes of stream output (without salt) are dropped.
(this hides the initial state sufficiently enough*, and costs very little in
processor time)
4. A salt is added to all final output bytes.
(a) The salt is defined as a [RIPEMD-160] HMAC buffer (keyed by *original* input key)
of the state as defined by steps 1-3 above.
(again, any hash in HMAC mode will work here, but use the same as the one above,
less code that way)
(b) A single persisted byte 'R' determines the index from the salt buffer to be used
next, and is initialized to 0 after steps 3 and 4(a).
(c) The salt byte at index 'R' is XOR'd with the next stream output byte, which is
obtained from the RC4 algorithm as normal. 'R' is then incremented, modulus the
length of salt buffer.
(d) Repeat step (c) as needed.
DISCLAIMER: USE AT YOUR OWN RISK, AND ONLY AFTER OBTAINING KNOWLEDGE OF THE LOCAL LAWS AND REGULATIONS OF YOUR JURISDICTION. AUTHOR MAINTAINS NO WARRANTY OF ANY KIND NOR OF ANY SOUNDNESS, VIABILITY, SECURITY, OR TRUSTWORTHINESS OF THIS CONCEPT! READER IS CAUTIONED AGAINST USING STRANGE ALGORITHMS FROM STRANGERS WITHOUT PRIOR CONSENT OF AN ADULT. YOU ARE ON YOUR OWN, AND AUTHOR ACCEPTS NO RESPONSIBILITY FOR WHAT YOU DECIDE TO DO WITH YOUR LIFE. THERE I SAID IT TWICE! NOW YOU HAVE NO EXCUSE!
But here's the rub. It was so widespread during the early days of many Internet and Wireless protocols (and is STILL used), you actually CAN'T get rid of it entirely, and you can't improve upon it without breaking compatibility with older systems.
This is probably the most frustrating aspect of ALL crypto-systems: Something that is great one day, can be (probably) broken in a short time frame (5-10 years or less), but is SO great, that it gets put into EVERYTHING before all hell breaks loose, and the industry as a whole is slow to adopt new tactics and algorithms, leaving the rest of us with "Swiss cheese security."
Take DES, as an example. It was developed a long time ago when computers were still HUGE, and desktop computing hadn't really happened yet. It was quickly broken as home computers became more and more powerful in the late 80's, and as cryptanalysts developed new techniques for getting algorithms to give up their secrets (quite literally) through careful bit manipulation and extensive comparison of inputs and outputs, it became clear that a new algorithm was needed.
In the move to get rid of DES, it was so prevalent, that the best anybody could do at the time (since DES was an adopted NIST FIPS standard) was to simply implement it 3 times in succession with a longer overall key (once forward, once backward, once again forward, each with a different, usually independent, piece of the overall key). Thus "Triple DES" or "3DES" was born. Hardly any new hardware required, and very little new software, just use what you have 3 times.
This was... ok... except it was later determined that the process of having the center transformation reversed caused some of the bits in the key to "not matter." Instead of 168 bits of security, you basically only get 112. Bummer.
And NIST calls it, effectively, 80. Double bummer.
And with modern hardware, a single DES key can be broken by brute-force in a matter of minutes or hours. Triple bummer. (see what I did there?)
Then came AES, which was chosen after a long competition held by NIST with some of the best crypto minds in the world (it was adopted in 2002 officially after an exhaustive process starting in 1997). It's only just now starting to show cracks (in 2011 or 2012, I can't find the original article, someone figured out that in the 256 bit version, the key expansion schedule had some peculiar behavior that COULD someday lead to an attack).
AES is now one of the most adopted algorithms in software*, because it's free, open source, and actually required for many US Government processes. (*I'm making an educated guess here based on my own experience.) It's even found its way into some Intel CPU architectures as a stand-alone Arithmetic Logic Unit (ALU), right alongside all the other key parts of the CPU. Try changing that out in all the PC's in the world if it were ever broken!
But I'm getting away from the plot...
RC4 was one of those algorithms that emerged and showed great promise due to its great speed and small memory footprint (less than 280 bytes in memory). It was so fast, in fact, that it was adopted when the first short-range, wireless connectivity standards were being implemented (remember 802.11a and WEP?). It does, however, still require a license (as of the time of writing this article) from RSA, the original developer.
The trouble is, by the time all the faults were discovered, 802.11a and all of its children were already in VERY widespread use. The idea of forcing manufactures and software vendors to change hundreds of thousands of devices (many of which had no way to "flash" new programs) was completely out of the question. New standards, which overcame SOME of the flaws, were later adopted (enter WPA, WPA2Personal/Enterprise), but the damage had already been done.
RC4 is dead! Long live RC4!
Yup, it's still out there, in use, in production, and it shouldn't be... but I digress.
One thing I will say, though, is that for quick-and-dirty encryption (read weak and probably easily cracked), its speed is largely unmatched. So even I dipped my toes in the water with a way to try and improve it, but I seriously doubt my way is any better than the last attempts.
But, if you need to use something small and lightweight... *wince* I can't recommend anything else that fits the same memory/code footprint *wince*. I would normally say use BlowFish, TwoFish, or even ThreeFish, but... *shrug* for this discussion, we're going "cheap"...
For starters, don't use the standard version in your final implementation (and not at all if you don't obtain a license from RSA; remember, this algorithm is still under their control). Do this instead:
DISCLAIMER: USE AT YOUR OWN RISK, AND ONLY AFTER OBTAINING KNOWLEDGE OF THE LOCAL LAWS AND REGULATIONS OF YOUR JURISDICTION. AUTHOR MAINTAINS NO WARRANTY OF ANY KIND NOR OF ANY SOUNDNESS, VIABILITY, SECURITY, OR TRUSTWORTHINESS OF THIS CONCEPT! READER IS CAUTIONED AGAINST USING STRANGE ALGORITHMS FROM STRANGERS WITHOUT PRIOR CONSENT OF AN ADULT. YOU ARE ON YOUR OWN, AND AUTHOR ACCEPTS NO RESPONSIBILITY FOR WHAT YOU DECIDE TO DO WITH YOUR LIFE.
Start with the standard version, just to build up the base, but remember that its flaws are numerous, and mostly surround the starting state, and the first 1000 bytes or so of output. From the standard, deviate with the following:
1. Input key is passed through [RIPEMD-160] hash first before the state is initialized.
(any decent hash will do, just stay away from MD5 and SHA-1; you don't need to go to
full SHA-512, or Skein, or Blake, or Keccak or anything like that, this is quick-
and-dirty after-all, right? Use all the bits that are output from the hash)
2. Initialization is increased from 1 pass through the state buffer to 3
(basically, increase from 256 key-based swaps to 768).
3. First 4096 bytes of stream output (without salt) are dropped.
(this hides the initial state sufficiently enough*, and costs very little in
processor time)
4. A salt is added to all final output bytes.
(a) The salt is defined as a [RIPEMD-160] HMAC buffer (keyed by *original* input key)
of the state as defined by steps 1-3 above.
(again, any hash in HMAC mode will work here, but use the same as the one above,
less code that way)
(b) A single persisted byte 'R' determines the index from the salt buffer to be used
next, and is initialized to 0 after steps 3 and 4(a).
(c) The salt byte at index 'R' is XOR'd with the next stream output byte, which is
obtained from the RC4 algorithm as normal. 'R' is then incremented, modulus the
length of salt buffer.
(d) Repeat step (c) as needed.
DISCLAIMER: USE AT YOUR OWN RISK, AND ONLY AFTER OBTAINING KNOWLEDGE OF THE LOCAL LAWS AND REGULATIONS OF YOUR JURISDICTION. AUTHOR MAINTAINS NO WARRANTY OF ANY KIND NOR OF ANY SOUNDNESS, VIABILITY, SECURITY, OR TRUSTWORTHINESS OF THIS CONCEPT! READER IS CAUTIONED AGAINST USING STRANGE ALGORITHMS FROM STRANGERS WITHOUT PRIOR CONSENT OF AN ADULT. YOU ARE ON YOUR OWN, AND AUTHOR ACCEPTS NO RESPONSIBILITY FOR WHAT YOU DECIDE TO DO WITH YOUR LIFE. THERE I SAID IT TWICE! NOW YOU HAVE NO EXCUSE!
Tuesday, April 16, 2013
Excel Column Name as a 0-based Index Number
This function is handy if you want to use packages like NPOI or EPPlus or some other Excel manipulation package.
Basically find the numeric value of the letter, and multiply it by the appropriate power of 26. Think of it like Base-26 numerals converting to decimal (or Base-10). The process is basically the same. We have to subtract 1 at the end because A is used like a 1 rather than a 0, and in Excel, the columns start from 1, not 0. So A=0, B=1,C=2, ... AA=26, AB=27, AC=28, ... ZA=676, ... AAA=702, etc. Although there is a limit to the number of columns in Excel 2007/2010 (I just can't remember it off the top of my head, and it's also dependent on if you are using 32bit Office or 64bit).
/// <summary>
/// Returns 0-based column number from Excel column name
/// string, like "G" or "ZD" or "DAJ".
/// </summary>
/// <param name="column"></param>
/// <returns></returns>
private static int GetIntFromColumnName(string column)
{
column = column.ToUpperInvariant();
const string alpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
int multiplier = (int)Math.Pow(26, column.Length - 1) ;
int result = 0;
char[] stuff = column.ToCharArray();
for (int scan = 0; scan < column.Length; scan++)
{
if (!alpha.Contains(stuff[scan]))
throw new ArgumentOutOfRangeException();
result += (alpha.IndexOf(stuff[scan]) + 1) * multiplier;
multiplier = (int)(multiplier / 26);
}
return result - 1;
}
Basically find the numeric value of the letter, and multiply it by the appropriate power of 26. Think of it like Base-26 numerals converting to decimal (or Base-10). The process is basically the same. We have to subtract 1 at the end because A is used like a 1 rather than a 0, and in Excel, the columns start from 1, not 0. So A=0, B=1,C=2, ... AA=26, AB=27, AC=28, ... ZA=676, ... AAA=702, etc. Although there is a limit to the number of columns in Excel 2007/2010 (I just can't remember it off the top of my head, and it's also dependent on if you are using 32bit Office or 64bit).
/// <summary>
/// Returns 0-based column number from Excel column name
/// string, like "G" or "ZD" or "DAJ".
/// </summary>
/// <param name="column"></param>
/// <returns></returns>
private static int GetIntFromColumnName(string column)
{
column = column.ToUpperInvariant();
const string alpha = "ABCDEFGHIJKLMNOPQRSTUVWXYZ";
int multiplier = (int)Math.Pow(26, column.Length - 1) ;
int result = 0;
char[] stuff = column.ToCharArray();
for (int scan = 0; scan < column.Length; scan++)
{
if (!alpha.Contains(stuff[scan]))
throw new ArgumentOutOfRangeException();
result += (alpha.IndexOf(stuff[scan]) + 1) * multiplier;
multiplier = (int)(multiplier / 26);
}
return result - 1;
}
Thursday, April 4, 2013
555 Based Constant Current Charge Circuit (UPDATED)
Ok, so first things first, I didn't come up with this.
Secondly, I'll probably be posting a followup and/or gutting this post to update any major changes, which, already I found one doing some troubleshooting. Each update will be in red, and outright fallacies will bestruck out or removed.
UPDATE May1st, 2013: Thirdly, the fab house where I bought my boards were themselves bought by another company (see below).
I'm borrowing heavily from the work of Kenneth Finnegan and Mike Davis. Mike came up with the idea of using the comparators and the latch inside of a 555 timer chip to do a charge/dump cycle for a battery charger powered from a solar panel. And Kenneth extended it a bit so that it's now a constant current charger.
The idea is that when a lead acid battery falls to 11.5V, it's considered discharged (at least if it's being stored, as lead acid batteries don't like being discharged below like 9V unless you're talking about a marine battery or an AGM battery). So the Trigger comparator (pin 2) looks for a low battery voltage set there (through a voltage divider), and then kicks the 555 on, which switches on an LM317 constant current circuit. Then the Threshold comparator (pin 6) will kick the 555 off again when the battery rises to about 14.2V, which is the point where most lead acid batteries should stop charging, although your mileage will vary (it should be written on the battery).
This does not go into the constant voltage stage of a charge cycle after the 555 kicks off, and there is resistance between positive and ground of the battery through the voltage dividers, so it WILL eventually drain the battery, BUT it should kick back in to charge it back up. So as long as there is power: No problem!
Go here for a great talk on lead acid batteries from Ken for more details on the whole process and the chemistry of these batteries. And also this great primer from Bill Hammack the Engineer Guy.
So, here is the circuit (see Kenneth's blog and Mike's post for the originals). (This is the prototype I had made, not the current circuit I'm working on, although if you can get this to work for you, please drop me a line with anything you learned along the way, as I seem to be getting different behavior from Ken)
I'm a bit of a n00b at Eagle, so there's extra pins for the pads where you connect the supply voltage and the battery connections instead of nice connectors or screw terminals. *shrug* It works, which is a win in my book, so... It is what it is.
The 7805 acts as a stable voltage reference against which the 555 checks the battery at VOUT. The trim pots need to be adjusted so that, when the VOUT pin is at 11.5 volts (the trigger or ON point for the battery to start charging), the voltage being fed into Pin 2 is about 1.667 volts (test point 1). Then adjust the other trim pot with VOUT at 14.2V so that the voltage at Pin 6 is at about 3.333 volts (test point 2). This should calibrate the charger for most lead acid batteries.
According to Ken, when the 555 output goes low (OFF), the LM317 constant current circuit shuts down, and the 1N5818 diode prevents damage to the rest of the circuit. Basically, with the Adjust pin pulled down through the transistor (which is there to prevent over-voltage to the 555), the voltage regulator output goes way down, to the point where the diode is reverse-biased. When the 555 goes high, the transistor stops conducting and the Adjust pin floats relative to the battery, and the current sensing resistor (R1). The current sensing resistor keeps the adjust pin just at the right point to bring the voltage high enough to conduct to the battery, but not so high as to draw too much current. Ken indicated on his blog that he has a switch to kick over to a 3ohm resistor instead of a 1.5ohm to allow for slower charging (half of the current). He doesn't have it listed in his circuit, and I opted to not use it either.
UPDATE: I've since come to realize that the 555 might be asked to do too much work with driving the LEDs and sinking the adjust pin of the LM317. I've replaced the NPN transistor with a PNP transistor that pulls the LM317 directly to ground, rather than through the 555. The 555 now drives the base of the transistor through the 4.7k resistor that was there before, rather than providing the ground path through itself. I noticed that if the charging LED was pulling too much current from pin 3, it was enough to start "dragging down" the LM317 through a partially conductive transistor and it would fall well below the battery preventing it from actually charging.
Here is my prototype which I ordered from BatchPCB. I had to send them the gerber files from my Eagle board file and wait about 2 weeks (note this board is the one currently uploaded on BatchPCB, not the completed prototype pictured below, which was version 1.0, this is 1.1). I'm already up to 1.2, which isn't on BatchPCB yet with the transistor change mentioned above.
UPDATE May1st, 2013: Also, see this note. BatchPCB has been bought out by OSH Park. Looks like I'll either need to follow their guide on migrating accounts, or just wait, and submit a board after I've done all my major edits and other proofs. This thing is difficult to troubleshoot, and my bench equipment sucks...
BatchPCBis used to be run by the people at Sparkfun Electronics. They have had a great service, but you should ONLY use it for prototyping. There's a $10 setup fee, and the individual board prices are... a bit high. But it's it was MEANT to be a prototyping house so that you don't have to buy 20 boards only to find out there are huge mistakes (like the one's I've listed or worse). They scooped up a number of orders and "panelize" them so they all get made at once, hence the wait. (The new service seems to offer somewhat quicker turn around but still using the same "bundle peoples' orders to save costs" scheme, and they also sell boards in "sets" so you get - at the time of writing this - 3 boards in a single order, which is actually cool) I got two in case I had to do green-wire surgery (turns out I do). Once you've proven out your board, go to a full-blown fab house to bring the cost way down.
Honestly, though, I'm really happy with the results. (OSH Park uses gold on purple, and they have tighter tolerances, so... we shall see... I might make this an SMD board after all. Then again I might just approach SparkFun and have them make/sell them)
This isn't the end of this board, I'm still making tweaks (as indicated above). Such as adding a filter cap on the output to stomp noise from reaching the 555. You can already see some changes from the silk screen (yellow) from the photos. I had to switch the LEDs, as they were labeled backwards, so you'll see lines drawn on the photos. I also had to move the mounting holes. Turns out there's this little thing called "clearance" you have to watch out for [/sarcasm]. But that's what a prototype is meant to weed out.
It needs an enclosure, which might also help with the noise-susceptibility problem, and ideally a fuse or two. And, I need like, 8 more of them... and the same number of power supplies (*yikes*). I have almost a dozen of those SLA's from old UPS equipment I've repaired for friends. I use them for portable power and to bilge out my sumps if I lose power (thank you marine supply store!). The hard part is keeping them charged for long stretches, and these boards are just what I needed... assuming I get more...
Secondly, I'll probably be posting a followup and/or gutting this post to update any major changes, which, already I found one doing some troubleshooting. Each update will be in red, and outright fallacies will be
UPDATE May1st, 2013: Thirdly, the fab house where I bought my boards were themselves bought by another company (see below).
I'm borrowing heavily from the work of Kenneth Finnegan and Mike Davis. Mike came up with the idea of using the comparators and the latch inside of a 555 timer chip to do a charge/dump cycle for a battery charger powered from a solar panel. And Kenneth extended it a bit so that it's now a constant current charger.
The idea is that when a lead acid battery falls to 11.5V, it's considered discharged (at least if it's being stored, as lead acid batteries don't like being discharged below like 9V unless you're talking about a marine battery or an AGM battery). So the Trigger comparator (pin 2) looks for a low battery voltage set there (through a voltage divider), and then kicks the 555 on, which switches on an LM317 constant current circuit. Then the Threshold comparator (pin 6) will kick the 555 off again when the battery rises to about 14.2V, which is the point where most lead acid batteries should stop charging, although your mileage will vary (it should be written on the battery).
This does not go into the constant voltage stage of a charge cycle after the 555 kicks off, and there is resistance between positive and ground of the battery through the voltage dividers, so it WILL eventually drain the battery, BUT it should kick back in to charge it back up. So as long as there is power: No problem!
Go here for a great talk on lead acid batteries from Ken for more details on the whole process and the chemistry of these batteries. And also this great primer from Bill Hammack the Engineer Guy.
So, here is the circuit (see Kenneth's blog and Mike's post for the originals). (This is the prototype I had made, not the current circuit I'm working on, although if you can get this to work for you, please drop me a line with anything you learned along the way, as I seem to be getting different behavior from Ken)
I'm a bit of a n00b at Eagle, so there's extra pins for the pads where you connect the supply voltage and the battery connections instead of nice connectors or screw terminals. *shrug* It works, which is a win in my book, so... It is what it is.
The 7805 acts as a stable voltage reference against which the 555 checks the battery at VOUT. The trim pots need to be adjusted so that, when the VOUT pin is at 11.5 volts (the trigger or ON point for the battery to start charging), the voltage being fed into Pin 2 is about 1.667 volts (test point 1). Then adjust the other trim pot with VOUT at 14.2V so that the voltage at Pin 6 is at about 3.333 volts (test point 2). This should calibrate the charger for most lead acid batteries.
According to Ken, when the 555 output goes low (OFF), the LM317 constant current circuit shuts down, and the 1N5818 diode prevents damage to the rest of the circuit. Basically, with the Adjust pin pulled down through the transistor (which is there to prevent over-voltage to the 555), the voltage regulator output goes way down, to the point where the diode is reverse-biased. When the 555 goes high, the transistor stops conducting and the Adjust pin floats relative to the battery, and the current sensing resistor (R1). The current sensing resistor keeps the adjust pin just at the right point to bring the voltage high enough to conduct to the battery, but not so high as to draw too much current. Ken indicated on his blog that he has a switch to kick over to a 3ohm resistor instead of a 1.5ohm to allow for slower charging (half of the current). He doesn't have it listed in his circuit, and I opted to not use it either.
UPDATE: I've since come to realize that the 555 might be asked to do too much work with driving the LEDs and sinking the adjust pin of the LM317. I've replaced the NPN transistor with a PNP transistor that pulls the LM317 directly to ground, rather than through the 555. The 555 now drives the base of the transistor through the 4.7k resistor that was there before, rather than providing the ground path through itself. I noticed that if the charging LED was pulling too much current from pin 3, it was enough to start "dragging down" the LM317 through a partially conductive transistor and it would fall well below the battery preventing it from actually charging.
Here is my prototype which I ordered from BatchPCB. I had to send them the gerber files from my Eagle board file and wait about 2 weeks (note this board is the one currently uploaded on BatchPCB, not the completed prototype pictured below, which was version 1.0, this is 1.1). I'm already up to 1.2, which isn't on BatchPCB yet with the transistor change mentioned above.
UPDATE May1st, 2013: Also, see this note. BatchPCB has been bought out by OSH Park. Looks like I'll either need to follow their guide on migrating accounts, or just wait, and submit a board after I've done all my major edits and other proofs. This thing is difficult to troubleshoot, and my bench equipment sucks...
BatchPCB
Honestly, though, I'm really happy with the results. (OSH Park uses gold on purple, and they have tighter tolerances, so... we shall see... I might make this an SMD board after all. Then again I might just approach SparkFun and have them make/sell them)
Tuesday, July 31, 2012
ADFS in SQL2012
This blog is probably going to have a number of edits as we trundle forward into glory, but the basic idea is Yes you can use SQL2012 with ADFS2.0 in Server 2008r2 and SharePoint 2010. BUT....
There are lots of caveats and there are script edits that need to be made due to commands that Microsoft deprecated in SQL2012 that used to work in SQL2008r2.
For more information, contact us at LiquidMercurySolutions.com for updated blogs and additional information. I assume Microsoft will patch or release an ADFS3.0 for Server 8 and SharePoint 15(2013?) that will be more correctly wired.
STAY TUNED!! ....
There are lots of caveats and there are script edits that need to be made due to commands that Microsoft deprecated in SQL2012 that used to work in SQL2008r2.
For more information, contact us at LiquidMercurySolutions.com for updated blogs and additional information. I assume Microsoft will patch or release an ADFS3.0 for Server 8 and SharePoint 15(2013?) that will be more correctly wired.
STAY TUNED!! ....
Tuesday, June 19, 2012
Crypto Gotcha's in .NET 3.5
Ok, so this is something they don't teach you but will cause you to rip your hair out when you attempt to use the AESManaged or RijndaelManaged objects in C#. Here are some tips that will save you a lot of headaches both on the encryption side and the decryption side:
1. SET YOUR PADDING METHOD AND MODE EXPLICITLY
If you just want zero's then fine, but be explicit! And do the same on the other side!
If you just want to use the Electronic Code Book (ECB) mode then fine, but spell it out!
2. ALWAYS SET YOUR KEY SIZE AND BLOCK SIZE EXPLICITLY, AND BEFORE SETTING THE ACTUAL KEY OR IV PARAMETERS
This kicked my ass for at least an hour before I tried moving the statements around on in a fit ofrage insight, under the heading of "this shouldn't work but crazier things have happened." I didn't change any of the VALUES for the statements, just the order in which they appeared in the code. And it worked, and I said DAMMIT "Wow I should be more careful!" out loud.
3. IF YOU USE RANDOM IV'S (and you should), SAVE AND/OR DISPLAY AND/OR EMBED THEM SOMEWHERE SAFE FOR THE DECRYPTION PROCESS
Your data will never come out looking the same again if you don't know what IV was set before you encrypted it. And I do recommend using an IV (yes an actual, non-null, random or pseudo-random, honest-to-goodness, IV),even ESPECIALLY with ECB mode, just to prevent prying eyes from detecting patterns in your streams!
using System.Security.Cryptography;
...
private string Decrypt(string B64Key, string B64IV, string B64data)
{
byte[] key = Convert.FromBase64String(B64Key);
byte[] IV = Convert.FromBase64String(B64IV);
byte[] data = Convert.FromBase64String(B64data);
//AesManaged can be dropped in here if needs be
RijndaelManaged myCrypto = new RijndaelManaged();
myCrypto.BlockSize = 128; // SET FIRST!
myCrypto.KeySize = 192; // SET FIRST!
myCrypto.Key = key;
myCrypto.IV = IV;
myCrypto.Mode = CipherMode.CBC;
myCrypto.Padding = PaddingMode.Zeros;
//change to Create.Encryptor and the function is reusable
ICryptoTransform ict = myCrypto.CreateDecryptor();
byte[] output = ict.TransformFinalBlock(data, 0, data.Length);
Encoding txtEncoder = new UTF8Encoding();
string result = txtEncoder.GetString(output);
// do post-processing here
if (!string.IsNullOrEmpty(result))
{
}
return result;
}
1. SET YOUR PADDING METHOD AND MODE EXPLICITLY
If you just want zero's then fine, but be explicit! And do the same on the other side!
If you just want to use the Electronic Code Book (ECB) mode then fine, but spell it out!
2. ALWAYS SET YOUR KEY SIZE AND BLOCK SIZE EXPLICITLY, AND BEFORE SETTING THE ACTUAL KEY OR IV PARAMETERS
This kicked my ass for at least an hour before I tried moving the statements around on in a fit of
3. IF YOU USE RANDOM IV'S (and you should), SAVE AND/OR DISPLAY AND/OR EMBED THEM SOMEWHERE SAFE FOR THE DECRYPTION PROCESS
Your data will never come out looking the same again if you don't know what IV was set before you encrypted it. And I do recommend using an IV (yes an actual, non-null, random or pseudo-random, honest-to-goodness, IV),
using System.Security.Cryptography;
...
private string Decrypt(string B64Key, string B64IV, string B64data)
{
byte[] key = Convert.FromBase64String(B64Key);
byte[] IV = Convert.FromBase64String(B64IV);
byte[] data = Convert.FromBase64String(B64data);
//AesManaged can be dropped in here if needs be
RijndaelManaged myCrypto = new RijndaelManaged();
myCrypto.BlockSize = 128; // SET FIRST!
myCrypto.KeySize = 192; // SET FIRST!
myCrypto.Key = key;
myCrypto.IV = IV;
myCrypto.Mode = CipherMode.CBC;
myCrypto.Padding = PaddingMode.Zeros;
//change to Create.Encryptor and the function is reusable
ICryptoTransform ict = myCrypto.CreateDecryptor();
byte[] output = ict.TransformFinalBlock(data, 0, data.Length);
Encoding txtEncoder = new UTF8Encoding();
string result = txtEncoder.GetString(output);
// do post-processing here
if (!string.IsNullOrEmpty(result))
{
}
return result;
}
Wednesday, December 28, 2011
SharePoint 2010 BCS Field - Setting the field/column
I found where SharePoint keeps the bodies!
...well at least where it keeps the tombstones.
[In SharePoint and other programming worlds, the term "tombstone" or "headstone" often refers to a link, ID, or other mechanism or value that references some other value, much like a pointer in C/C++ terms.]
For BCS columns, I couldn't find a good article to automatically do the look-up and set the related fields of an External Content Type (ECT) field/column for SharePoint 2010 (pure 2010 mind you). The code I COULD find was for SharePoint 2007, ported to 2010, but the objects and DLL's referenced in all of the examples were rendered OBSOLETE by Microsoft, so I couldn't compile against them. This was a total bummer and a set-back, because those methods used to actually work (according to the comments people posted on those articles and blogs).
What I WAS able to find, was that, for MS SQL tables at least, there was a "__b" string that was stored in each item of a purely external list that referenced the external row. You could see it as you hovered over the item in the list, the URL would contain a string at the end ..."&ID=__b"... blah blah blah. That blah portion could be a complex number, or a dressed-up GUID, whatever the primary key identifier field was in SQL, but it ALWAYS started "__b" (again, this is for MS SQL, your mileage may vary). I tested this value by creating a new item in a different list that had that ECT column, and when I did the look up against the value, it pulled back the record!!! EUREKA!
So if I set the value for that field in code (ala "theItem["Field"] = stuff.ToString();") then it should work, right? WRONG! You'll see that the value might be set, or it might not be (random), and the value won't actually look itself up. :( Also if you run a workflow against the field and attempt to get anything like "[field: OtherTableRelatedField]" it will error out, telling you that the value isn't in the expected format, which will halt a workflow at "Error Occurred". The look-up works in the UI in the Edit or New form with no problems, but not from code, be it client object model, server object model, or PowerShell.
HOWEVER! Afterwards, you can do a refresh using the little icon next to the ECT column title in a view through the GUI to force it to refresh against the external content, and it will parse the entire list and update any rows that are out of date, or that contain a tombstone ("__b") value. AND THEN IT WILL DO THE LOOK-UP! Afterwards, your workflows and other code will operate just fine; the related fields will have the appropriate data in them.
I have found NO WAY to automatically or programmatically kick off that refresh so that the field will be set correctly at the time that I set it. :( So... this is basically a hack, and an 80% solution.
Also, I should point out, that tombstone value that points to the DB row (that "__b" value) is stored in a RELATED field to the ECT column, in a Multiple Lines of Text (Notes) type field! This is not easy to find when debugging, so it took me the better part of a day! I also wasn't aware of that "__b" value even existed until a coworker of mine pointed it out to me (who isn't even a programmer, but works with workflows all the time, Thanks Jason!).
Here's how you get that value in code:
This will provide the value. Then to stuff it back in to a new item that I had created moments before (in this case, a document set), I had to do this, with AllowUnsafeUpdates set to true around the block of code:
This will literally set the field value to that "__b" string, at which point, you must do a refresh on the column through the UI (which does EVERY ITEM IN THE LIST!) in order for SharePoint to replace the tombstone with actual data from the external system.
If someone can get me the rest of the way with this, I would GREATLY appreciate it, but at least this "hack" might be useful to some other developer.
Happy Hacking, and Merry Coding!
...well at least where it keeps the tombstones.
[In SharePoint and other programming worlds, the term "tombstone" or "headstone" often refers to a link, ID, or other mechanism or value that references some other value, much like a pointer in C/C++ terms.]
For BCS columns, I couldn't find a good article to automatically do the look-up and set the related fields of an External Content Type (ECT) field/column for SharePoint 2010 (pure 2010 mind you). The code I COULD find was for SharePoint 2007, ported to 2010, but the objects and DLL's referenced in all of the examples were rendered OBSOLETE by Microsoft, so I couldn't compile against them. This was a total bummer and a set-back, because those methods used to actually work (according to the comments people posted on those articles and blogs).
What I WAS able to find, was that, for MS SQL tables at least, there was a "__b" string that was stored in each item of a purely external list that referenced the external row. You could see it as you hovered over the item in the list, the URL would contain a string at the end ..."&ID=__b"... blah blah blah. That blah portion could be a complex number, or a dressed-up GUID, whatever the primary key identifier field was in SQL, but it ALWAYS started "__b" (again, this is for MS SQL, your mileage may vary). I tested this value by creating a new item in a different list that had that ECT column, and when I did the look up against the value, it pulled back the record!!! EUREKA!
So if I set the value for that field in code (ala "theItem["Field"] = stuff.ToString();") then it should work, right? WRONG! You'll see that the value might be set, or it might not be (random), and the value won't actually look itself up. :( Also if you run a workflow against the field and attempt to get anything like "[field: OtherTableRelatedField]" it will error out, telling you that the value isn't in the expected format, which will halt a workflow at "Error Occurred". The look-up works in the UI in the Edit or New form with no problems, but not from code, be it client object model, server object model, or PowerShell.
HOWEVER! Afterwards, you can do a refresh using the little icon next to the ECT column title in a view through the GUI to force it to refresh against the external content, and it will parse the entire list and update any rows that are out of date, or that contain a tombstone ("__b") value. AND THEN IT WILL DO THE LOOK-UP! Afterwards, your workflows and other code will operate just fine; the related fields will have the appropriate data in them.
I have found NO WAY to automatically or programmatically kick off that refresh so that the field will be set correctly at the time that I set it. :( So... this is basically a hack, and an 80% solution.
Also, I should point out, that tombstone value that points to the DB row (that "__b" value) is stored in a RELATED field to the ECT column, in a Multiple Lines of Text (Notes) type field! This is not easy to find when debugging, so it took me the better part of a day! I also wasn't aware of that "__b" value even existed until a coworker of mine pointed it out to me (who isn't even a programmer, but works with workflows all the time, Thanks Jason!).
Here's how you get that value in code:
SPFieldMultiLineText notes = theItem.Fields.GetField(
theItem.Fields["ECTField"].RelatedField)
as SPFieldMultiLineText; // notice the nesting?
string tombstone = notes.GetFieldValueAsText(
theItem[theItem.Fields["ECTField"].RelatedField]); // more nestingThis will provide the value. Then to stuff it back in to a new item that I had created moments before (in this case, a document set), I had to do this, with AllowUnsafeUpdates set to true around the block of code:
SPBusinessDataField dataField = theItem.Fields["ECTFieldName"] as SPBusinessDataField; // external data column
theWeb.AllowUnsafeUpdates = true;
dataField.ParseAndSetValue(theItem, tombstone);
theItem[dataField.RelatedField] = theItem["ECTFieldName"];
theItem.UpdateOverwriteVersion();
// if you do theItem.SystemUpdate() instead,
// workflows won't kick off
theList.Update(true); // not sure if this is needed?
theWeb.AllowUnsafeUpdates = false;This will literally set the field value to that "__b" string, at which point, you must do a refresh on the column through the UI (which does EVERY ITEM IN THE LIST!) in order for SharePoint to replace the tombstone with actual data from the external system.
If someone can get me the rest of the way with this, I would GREATLY appreciate it, but at least this "hack" might be useful to some other developer.
Happy Hacking, and Merry Coding!
Subscribe to:
Posts (Atom)