For a project I had to calculate parameters needed to make nice rectangular PCB inductor for a NFC antenna. Since my search didn’t bear desired results, I decided to make my own.
Enjoy.
| mm | ||
| mm | ||
| oz | ||
| mil | ||
| mil | ||
| mm | ||
| mm | ||
| mm | ||
| μH | ||
Calculation is done per NXP’s AN1445.
I had SSL enabled on my site for a while now. My hosting provider had it available as an option and I hated having my password travel unencrypted. However, as Google pushed for https, I started playing with the idea to use https exclusively. As you can (hopefully) see, migration was successful.
First order of business was to sort out redirects. I wanted regular http domain 301-redirected to the https one. As my server was using Apache, following directives were added to .htaccess file:
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [R=301,L]In order to be compliant with HTTP Strict Transport Security, I also added new header just above conditions in the same file:
Header always set Strict-Transport-Security "max-age=31536000; includeSubDomains"My Suffusion WordPress theme kept using http to fetch ads and that caused browsers to omit them all together (you cannot load http scripts on https site). Therefore I also had to make a slight modification to it. In file ./suffusion/functions/shortcodes.php I had to change suffusion_sc_ad function to use https by removing protocol name from the URL:
function suffusion_sc_ad($attr) {
$params = array('client', 'slot', 'width', 'height');
$provider = 'google';
$provider_type = 'syndication';
$service = 'ad';
$service_type = 'page';
$ret = "<div id='".$service."sense'>\n<script type='text/javascript'><!--\n";
foreach ($params as $var) {
$ret .= "\t".$provider."_".$service."_$var = '".$attr[$var]."';\n";
}
$ret .= "//-->\n</script>\n";
$service_url = "!!http:!!//".$service_type.$service."2.$provider$provider_type.com/$service_type$service/show_{$service}s.js";
$ret .= "<script type='text/javascript' src='$service_url'></script>\n";
$ret .= "</div>\n";
return $ret;
}Result of these three changes is that my site is now https-only without any functionality loss.
PS: Those checking the certificate will notice that I use CloudFlare and their Universal SSL. Do notice that using such service is actually one big man-in-the-middle attack since CloudFlare decrypts all traffic before encrypting it again when it contacts your site. It is not because they are evil but because they cannot provide you with their CDN services (and more) any other way. For any website traffic, I see no problem with such approach. However, for administration tasks, I would recommend having a separate https subdomain that leads directly to your server.
Serial port ruled the hobby market when connecting custom electronics to a computer was needed. As USB became prevalent, instead of serial interface we got USB-to-UART chips. Most common ones were manufactured by Prolific and FTDI and they became defacto standard. I personally chose FTDI’s FT232RL for huge majority of my designs. Partly it was due to driver availability for almost any platform and partly due to my bad experience with Prolific’s PL-2303.
Mid October FTDI pushed new WHQL certified driver via Windows Update. For quite a few customers that meant death of their serial devices. And it wasn’t just a compatibility issue. Once some devices saw new driver they became unusable on other operating systems (yes, including Linux). For more information, there is a huge thread at EEVblog forum along with some other sources.
Story started when the FTDI engineering found a way to detect some (if not all) non-genuine chips reprogramming them in process. For all practical purposes any device containing fake, cloned or compatible chip became dead. You could boot into Linux and previously working device would refuse to cooperate. You could even move it to another computer (without driver update) and it still wouldn’t work. While change is reversible by the expert user, normal user would just assume device is dead.
Were they in the right to detect fake devices and not work with them? For fakes chips answer is most definitive yes. It is a bit of a gray area when it comes to the compatible chips that have no FTDI markings. But actually killing the end-user devices is taking “pirate” fight a step too far. I am not necessarily talking about legality of “bricking” devices; I am sure that we will see at least legal analysis if not a legal action due to this.
As it works currently, in hobby market, you almost never contact manufacturer directly. You typically go via third-party. Whether you get legitimate or counterfeited chips is mostly a function of price. But you can get a real chip for cheap (e.g. somebody selling unused stock) and you can get a fake for a full price. Yes, you are more likely to get a original if you deal with a big/official suppliers (e.g. DigiKey, RS, Farnell/Newark/Element 14/whatever-is-their-name-now) but they are pain to deal if you are from in “unsupported” country. And a dollar difference here or there might make a difference to a hobby user.
As you sell a few devices with everything looking peachy they all suddenly stop working. Devices start coming back and you need to issue refunds or give a new device with a genuine chip. In an ideal world, you would sue your supplier and recover your damages. In reality you just swallow the loss because having a day in court would cost much more (in both time and money) than what you can hope to win. Only thing you can do is to avoid troublesome chip in the future. Once burned twice shy.
Similar problem exists if you bought a hardware device with the purest intentions. Price was right, not too high, not too low, functionality was just right and device used a FTDI chip internally (e.g. quite a few Arduinos, some BusPirate versions, humble chip breakout, or even some boards I made). But device manufacturer either used fake part knowingly or they just got screwed. In former case device was happily working until suddenly unrelated driver update killed it. If device is new you might get a refund. But chances are that you’ll get nothing.
If you are doing more than a few devices chances are you’re probably outsourcing assembly to somebody else. Dealing with assembly is handful on the best of days and now suddenly you might have on your hands a bunch of devices that pass all possible tests on the assembly bench only to be bricked by the end-user’s computer. To anybody other than the biggest manufacturers this is a scenario from hell. You will need to replace quite a few devices with assembler claiming devices work on their end and that it is not their issue. Court may be your friend but money/time equation usually does not work out.
And it is not as this fixes issue of fake devices. Those making fakes will just adjust their firmware to behave as a real FTDI chip for this case and Whac-A-Mole starts anew. I personally see a much higher chance that some later driver update will accidentally kill some genuine chips rather than preventing cloning. Recognizing that problem, FTDI CEO did say “sorry” but with a side dish of “we’ll do something else less drastic next time”.
I will personally vote with my wallet until I see what next few months will bring in this FTDI saga.
PS: If you want to get away from the FTDI but you don’t want to rework your board, there is a Cypress CY7C65213-28PVXI. It is pretty much exact pinout (albeit without possibility of an external oscillator), supporting anything from Windows 98 onward, and at a lower cost.
PPS: Those prepared to change board can look at MCP2221.
PPPS: Yes, I am aware my actions are purely cosmetic since I only buy 20ish FTDI chips a year.
[2016-02-05: They’re at it again. This time not bricking, just messing with data output.]
These days it is almost a common knowledge that J standing alone has a meaning of a smile. What you see as a J on the desktop suddenly becomes a letter J when viewed on (Android) phone. But why is that?
Answer lies in the dark times before the Unicode when only possibility to introduce new symbols was to actually swap some characters for them. It was quite a common practice to make fonts that consisted purely of symbols.
One of such fonts were Wingdings family. These fonts were then used in anything from Word to many custom programs. If your platform doesn’t support fonts or contains no Wingdings font (as Android), you would see symbols substituted for the letter characters.
Probably most commonly used in the emails are smiley symbols: J (J), K (K), and L (L). As Unicode became standard in communication, only smiley and frowny face survived. Other Wingdings characters remained just a curiosity and something you would get from Outlook users.
But maybe they will be coming back into fashion soon as Unicode 7.0 will contain most of them. Who knows, maybe even somebody makes an effort and J-weirdness becomes a history.
Back in the 2011, I bought CoPilot GPS; application for Android (it was called CoPilot Live back then). It came quite pricey at $70 (with full Europe and North America maps) but I considered an offline GPS a worthwhile investment.
As I stopped traveling as much I also stopped using CoPilot regularly. I still kept it updated and I still used it on occasional weekend without any issue. As I prepared for my vacation in Croatia, I was sure I had everything I need. I had a full contingent of North American maps along with most of Europe. I always make it a point to download Croatian maps first so I felt quite prepared.
Move forward a few days and I have landed in Croatia. I turned on my CoPilot GPS only to be greeted with an empty screen. Quick search gave me a solution - just reinstall everything. I did as it was written and got a new error - my account seemed not to exist any more. It was time to contact customer service.
After quite a fast initial reply I was asked to share my user name and password with them. In my mind there is NO GOOD REASON why a customer service would want your password. Only possible reason is that their system isn’t build right. However I used unique password for CoPilot anyhow and I was in hurry so I complied hoping it will help solve problem faster.
Fast-forward three weeks, FIVE separate queries for my password, three screenshots of actual error and me sending them original purchase e-mails (why they don’t have access to purchase e-mails is beyond me). All that and I only had my account back. On the very last day of my Croatian trip I also had a map of Croatia working but WITHOUT navigation support - in other words, CoPilot was still useless.
I am back in the States at this time, well into the third week of the CoPilot troubleshooting and I finally got my European maps back. But, alas, I still have no North American maps assigned to my account. My Croatian maps might be working at this time but I am not there anymore. I will update this post as situation unravels.
Few years ago I might have been in trouble for these three weeks but not today. As I noticed that this CoPilot issue was going south, I bought a prepaid SIM with 1 GB data for about $5. This allowed me to use Google Maps and they worked flawlessly. Yes, CoPilot might be more configurable and I personally prefer it since it feels and works as a real car GPS should. But all that was spoiled by it not working at all. I am scared to think how my vacation would look in the country I didn’t know and without readily available prepaid SIMs.
Yes, I will continue using CoPilot in future because it is a really good application - when it works. I just won’t recommend it without any reservation.
[2014-10-15: I finally got my maps back. Maybe it is just fortunate timing but I got them back minutes from tweeting their support (@copilotsupport). Note to self for next time: first tweet support and then open a ticket.]