Is it just me or are all 3,5mm stereo cables just junk? And with this I mean cables with 3,5mm stereo plug in both ends, used to connect, say, your phone to car radio's AUX or something else, like my new(ish) Zekler hearing protector with radio.
In this case I got the 412R model (radio and 3,5mm AUX) because I wanted to listen audiobooks while working and the equivalent bluetooth model was about three to four times the price (can't remember exact numbers, this was about a year ago), a bit too much for my taste. Granted, if I were buying new set now I might consider bluetooth model as it turns out that that wire happens to be on the way quite often when doing light buy noisy (think chainsaws, lawnmowers etc...) physical activities no matter how you try to hide it under your shirt.
Anyway, I think I have clocked only few tens of hours, but absolutely no more than hundred hour of use for the protectors and the 3,5mm audio cable that came with the set is already broken - right channel keeps cutting off. This isn't the first audio extension cable I have ruined either, for some reason those seem to always keep breaking way too soon.
Some time ago I opened one out of curiosity and found out that the wires were really thin - a few strands of copper (if it even is copper...) with thickness of human hair - and soldering job was just horribly bad. No wonder they keep breaking, even slightest mechanical stress either breaks bad solder joints or breaks those thin wires...
torstai 28. toukokuuta 2015
perjantai 22. toukokuuta 2015
All hail solar panels
I have chosen to avoid politics in my posts, but this gets fairly close. So please, before proceeding, take a deep breath and consider the numbers mentioned before getting angry.
It seems that renewable energy sources - especially wind and solar - are all the rage these days. While in some locations it makes kinda sorta sense, from my perspective the problem is that I live at fairly northern location - namely Finland, and where I exactly am the annual average temperature is slightly less than three degrees Centigrade (around 39F). Northern location also means that temperature varies wildly over the years (lowest daily average being around -10 degrees C, and lowest winter temperature often is -30 .. -40 C range), as well does the solar insolation.
Just for the fun of it I did the math on how much solar panels would be needed to cover electrocity usage of Finland with solar only. Sorry I'm not giving the worksheet, it's really messy, but the numbers I'm basing this are following (and should be easily found with some seaches, albeit the document I took electricity figues from is in Finnish only - I'm sure equivalent info is available).
Number of households: 2 532 000 (note that this includes everything from 1-room apartments to huge mansions)
Winter-time panel energy, optimized for winter production (ie 60 degree tilt): 0,86 kWh/m2/day.
Average maximum power usage in winter: 13000MW (approximate, there is variance from 11000MW to 14000MW over typical day). Of this, renewables (mostly water power) cover currently about 2500MW, leaving about 10500MW for imported electricity and non-renewables. So let's use that as base for calculations.
Extending that average usage over day, divided by production, says that we will need approximately 293023255 square meters, 293 square kilometres, or 114,5 square miles of panels to cover that usage. That is pretty frickin' huge land area!
Again, dividing that by number of households means that every single household would need about 115 square meters (very roughly 1150 sq ft) of panels if these were installed on roofs. At this point I'd like again to remind that many of those households are in apartments, making it impossible for them to have that large area of panels, and many older (smaller) houses don't even have that much surface area to begin with.
At the moment of writing (late May) the total electricity usage hovers around 8500MW mark (unfortunately I didn't check insolation and I'm being too lazy to search again so I'm taking a guess of 3 kWh/m2/day (summer maximum being 5,3kWh/m2/day) - which would drop these figures to 48 square kilometes of panels, or about 19 square meters per household. This of course assumes all-solar, that of course is insane goal.
Now moving to next issue: winter is pretty damn dark around here. In january we get some 4 to 6 hours of light, sun being very low at horizon. Not much sunlight to capture there. So let's give a optimistic figure and say that we get whopping 8 hours of usable sunlight a day that produces all the energy we need, and we only have to cover only half of the winter energy usage calculated above with solar (let's say round 5000MW), rest coming from something else (with what is another question but let's just ignore that for now).
So this means that over that 8-hour period we need to store total of 120000000kWh of energy, or 47kWh per household somewhere. That won't be easy either. While Tesla's PowerWall and future iterations may help a bit there, the problem with batteries is that they wear down and when something goes wrong they behave .. well, let's just say unpleasantly. And when dealing amount of batteries needed here and huge amount of charge/discharge cycles, something will go wrong every now and then.
What I'm trying to say: While solar is great (and make no mistake, I love the idea -- I have done the math for my personal use over and over again but the numbers still haven't turned out financially worth it, no matter how I try), there is currently absolutely no way it could be reliably replace even small part of current baseline production. Yet whenever there is news or discussions about solar, these problems are never mentioned, or if they are, no one is willing to answer questions about this - least those who most vocally want to increase solar usage. Wonder why?
And do note, above I have spoken only of electricity. If you want to get rid of fossil fuels, above numbers don't include oil, LNG and other forms of fossil fuels used for other purposes like cars and airplanes, so you have to add their energy on top too.
It seems that renewable energy sources - especially wind and solar - are all the rage these days. While in some locations it makes kinda sorta sense, from my perspective the problem is that I live at fairly northern location - namely Finland, and where I exactly am the annual average temperature is slightly less than three degrees Centigrade (around 39F). Northern location also means that temperature varies wildly over the years (lowest daily average being around -10 degrees C, and lowest winter temperature often is -30 .. -40 C range), as well does the solar insolation.
Just for the fun of it I did the math on how much solar panels would be needed to cover electrocity usage of Finland with solar only. Sorry I'm not giving the worksheet, it's really messy, but the numbers I'm basing this are following (and should be easily found with some seaches, albeit the document I took electricity figues from is in Finnish only - I'm sure equivalent info is available).
Number of households: 2 532 000 (note that this includes everything from 1-room apartments to huge mansions)
Winter-time panel energy, optimized for winter production (ie 60 degree tilt): 0,86 kWh/m2/day.
Average maximum power usage in winter: 13000MW (approximate, there is variance from 11000MW to 14000MW over typical day). Of this, renewables (mostly water power) cover currently about 2500MW, leaving about 10500MW for imported electricity and non-renewables. So let's use that as base for calculations.
Extending that average usage over day, divided by production, says that we will need approximately 293023255 square meters, 293 square kilometres, or 114,5 square miles of panels to cover that usage. That is pretty frickin' huge land area!
Again, dividing that by number of households means that every single household would need about 115 square meters (very roughly 1150 sq ft) of panels if these were installed on roofs. At this point I'd like again to remind that many of those households are in apartments, making it impossible for them to have that large area of panels, and many older (smaller) houses don't even have that much surface area to begin with.
At the moment of writing (late May) the total electricity usage hovers around 8500MW mark (unfortunately I didn't check insolation and I'm being too lazy to search again so I'm taking a guess of 3 kWh/m2/day (summer maximum being 5,3kWh/m2/day) - which would drop these figures to 48 square kilometes of panels, or about 19 square meters per household. This of course assumes all-solar, that of course is insane goal.
Now moving to next issue: winter is pretty damn dark around here. In january we get some 4 to 6 hours of light, sun being very low at horizon. Not much sunlight to capture there. So let's give a optimistic figure and say that we get whopping 8 hours of usable sunlight a day that produces all the energy we need, and we only have to cover only half of the winter energy usage calculated above with solar (let's say round 5000MW), rest coming from something else (with what is another question but let's just ignore that for now).
So this means that over that 8-hour period we need to store total of 120000000kWh of energy, or 47kWh per household somewhere. That won't be easy either. While Tesla's PowerWall and future iterations may help a bit there, the problem with batteries is that they wear down and when something goes wrong they behave .. well, let's just say unpleasantly. And when dealing amount of batteries needed here and huge amount of charge/discharge cycles, something will go wrong every now and then.
What I'm trying to say: While solar is great (and make no mistake, I love the idea -- I have done the math for my personal use over and over again but the numbers still haven't turned out financially worth it, no matter how I try), there is currently absolutely no way it could be reliably replace even small part of current baseline production. Yet whenever there is news or discussions about solar, these problems are never mentioned, or if they are, no one is willing to answer questions about this - least those who most vocally want to increase solar usage. Wonder why?
And do note, above I have spoken only of electricity. If you want to get rid of fossil fuels, above numbers don't include oil, LNG and other forms of fossil fuels used for other purposes like cars and airplanes, so you have to add their energy on top too.
maanantai 18. toukokuuta 2015
Inside USB 3G module
After some cleaning up I found an old USB 3G net stick that I got for some reason but never used. Just lately I upgraded to LTE equipment so this specific stick is completely useless for me now.
(and over just last two weekend I used some 26GB of data (most being TV streaming on laptop while away from home ) according to counter on top of device - and by the way, it costs me 15€ a month total, no data caps at all).
Out of curiosity I decided to tear that open before throwing it away, although I had pretty good idea what would be inside. After all, I had some time while waiting for my new purchase to work its magic...
...but more about that toy later.
Outside it's ... well, a stick. Stupidly long though so you have to be somewhat careful if you're using it with laptop on your lap.
Some gentle persuasion...
...and after opening two covered screws next to USB connector it was open. Approximately as I expected so far. Note two antennas, one at the end of stick and other on the cover as simple piece of metal. White piece of plastic is light guide for LEDs that can be seen just above small chip outside metal shield.
Other side after taking the metal shields off. Here we have Qualcomm RTR6285 - GSM/WCDMA transceiver chip and Qualcomm PM6658 of which I couldn't find any usable information about (and yes, SIM/MicroSD holder too, stick works as USB storage too if you have SD card in it)
Other side again. Qualcomm MSM6246 - 3G HSDPA chipset (and most likely application processor too) and Samsung K5D1258DCB chip - again I couldn't quickly find any reliable information but it seems to be a Flash chip. There was a strip of metal over MSM chip but I cut it and bent it away to see markings as you can see in the image.
Left side is dedicated to RF; Avago FEM-7780 (UMTS front-end), Avago ACPM-7371 (UMTS 4x4 power amp for 900MHz) and RF3161 (GSM/EDGE amplifier). There were some other chips too but their markings didn't exactly fill me with confidence that I'd find anything relevant so I didn't even bother trying.
So there, as expected it's made of mostly off-the-shelf parts, probably closely duplicating some reference design directly available from Qualcomm (well, directly available -- after you have convinced them that they should and would want to do business with you and signing a full cabinet's worth of contracts, NDAs and other paperwork.)
(and over just last two weekend I used some 26GB of data (most being TV streaming on laptop while away from home ) according to counter on top of device - and by the way, it costs me 15€ a month total, no data caps at all).
Out of curiosity I decided to tear that open before throwing it away, although I had pretty good idea what would be inside. After all, I had some time while waiting for my new purchase to work its magic...
...but more about that toy later.
Outside it's ... well, a stick. Stupidly long though so you have to be somewhat careful if you're using it with laptop on your lap.
Some gentle persuasion...
...and after opening two covered screws next to USB connector it was open. Approximately as I expected so far. Note two antennas, one at the end of stick and other on the cover as simple piece of metal. White piece of plastic is light guide for LEDs that can be seen just above small chip outside metal shield.
Other side after taking the metal shields off. Here we have Qualcomm RTR6285 - GSM/WCDMA transceiver chip and Qualcomm PM6658 of which I couldn't find any usable information about (and yes, SIM/MicroSD holder too, stick works as USB storage too if you have SD card in it)
Other side again. Qualcomm MSM6246 - 3G HSDPA chipset (and most likely application processor too) and Samsung K5D1258DCB chip - again I couldn't quickly find any reliable information but it seems to be a Flash chip. There was a strip of metal over MSM chip but I cut it and bent it away to see markings as you can see in the image.
Left side is dedicated to RF; Avago FEM-7780 (UMTS front-end), Avago ACPM-7371 (UMTS 4x4 power amp for 900MHz) and RF3161 (GSM/EDGE amplifier). There were some other chips too but their markings didn't exactly fill me with confidence that I'd find anything relevant so I didn't even bother trying.
So there, as expected it's made of mostly off-the-shelf parts, probably closely duplicating some reference design directly available from Qualcomm (well, directly available -- after you have convinced them that they should and would want to do business with you and signing a full cabinet's worth of contracts, NDAs and other paperwork.)
keskiviikko 13. toukokuuta 2015
When fullscreen ain't ...
Small annoyances of life ...
I've been subscriber of EDN newsletter for long time now. I think this is the very same newsletter I subscribed on paper back in early 2000s or so but can't be exactly sure (for completely free!), and I still kinda miss the paper version. There's just something about handling paper that is missing from digital...
(kinda related: Just few days I went to a nearby playground with the kid. I took my Kindle with me, just in case I had some time to read. Unfortunately battery had been drained in meantime and since e-ink screen retained the last image I only found out in the park. No reading for me then... So score one for paper there too.)
Anyway, I just got the newest edition of EDN, and as usual I opened the flash version as full screen as usual. Execept I got this (copy of my entire screen, 1920x1200 original, only scaled down):
Are you kidding me? That doesn't look like full screen to me, not even close! I have big screen for a reason, don't make me squint for it like that trying to read tiny text...
And no, I don't mind the ads, especially since entire magazine is essentially nothing but product "infomercials". The thing is that there occasionally is something interesting and/or useful, like mention of new 4Mbit FRAMs now -- I haven't been too happy of FRAM sizes previously anyway but nonvolatile memory with essentially infinite write cycles is just-so-damn-useful...
I've been subscriber of EDN newsletter for long time now. I think this is the very same newsletter I subscribed on paper back in early 2000s or so but can't be exactly sure (for completely free!), and I still kinda miss the paper version. There's just something about handling paper that is missing from digital...
(kinda related: Just few days I went to a nearby playground with the kid. I took my Kindle with me, just in case I had some time to read. Unfortunately battery had been drained in meantime and since e-ink screen retained the last image I only found out in the park. No reading for me then... So score one for paper there too.)
Anyway, I just got the newest edition of EDN, and as usual I opened the flash version as full screen as usual. Execept I got this (copy of my entire screen, 1920x1200 original, only scaled down):
Are you kidding me? That doesn't look like full screen to me, not even close! I have big screen for a reason, don't make me squint for it like that trying to read tiny text...
And no, I don't mind the ads, especially since entire magazine is essentially nothing but product "infomercials". The thing is that there occasionally is something interesting and/or useful, like mention of new 4Mbit FRAMs now -- I haven't been too happy of FRAM sizes previously anyway but nonvolatile memory with essentially infinite write cycles is just-so-damn-useful...
tiistai 5. toukokuuta 2015
STM32F4 Discovery USB HID, with sources
As promised, here it is. Minimalistic device-only USB HID example, adapted from STMicroelectronics libraries.
The zip included here includes (hopefully) all necessary sources to compile it, assuming you have ARM GCC based toolchain (including make) installed. Either run make directly or use included c.bat that invokes that for you. There is pre-built binaries too if you want to test this on your board first.
ZIP file here.
The example implements HID protocol with same VID/PID as Discovery examples. When running it will flash green led (PG13) continuously (but at quite high frequency, resulting it to just seem dim) and red led (PG14) when a USB packet is received from computer. It also will echo same packet with every byte within it increased by one back to computer.
Now, on PC side the easiest way I found was to use HID API library. As proper precompiled DLL for that was almost impossible to find so I included DLL (release build with visual studio 2013 directly from HID API sources) in zip too, but no other sources for PC side application as my test is based on ancient Borland C++ Builder 4 which you very likely you do not have; this also is the reason I had trouble with DLL as compiling the HID API DLL with that BCB was way too difficult (luckily I had some help). However, examples provided at HID API site should be easy enough to adapt for your preferred compiler though. (and I just realised that .lib file is not included there either, d'oh, as BCB lib will not work with other compilers... Well, I hope you will manage anyway) (and if you absolutely want to have the BCB project, drop me a line, I'll upload that too)
On some usage details;
Relevant (and somewhat modified) files from STM libraries are all placed in usblib directory, and main usb file is usb.c. In your main you only need to included usb.h and call usbInit(). To send packets use usbSend() function and on receive side you'll need to re-implement usbReceiveHandler() function to do your own processing. See comments here for further details.
Packet size is fixed to 64 bytes (1 byte report ID + 63 bytes user payload) so trying any other packet sizes will not work (read: will result an error) unless you change the report descriptors in sources. I've tried to add relevant comments here and there to make it easier to adapt it for your use but I expect it will take some studying anyway.
This is primarily for USB OTG HS (MicroUSB connector) on Discovery board with LCD, hopefully it will work on models without display too, as pin setup in usb_bsp.c is quite hardcoded for this setup (and actually will not work for any other type of interface as I've very likely broken other #ifdef branches in the process).
The zip included here includes (hopefully) all necessary sources to compile it, assuming you have ARM GCC based toolchain (including make) installed. Either run make directly or use included c.bat that invokes that for you. There is pre-built binaries too if you want to test this on your board first.
ZIP file here.
The example implements HID protocol with same VID/PID as Discovery examples. When running it will flash green led (PG13) continuously (but at quite high frequency, resulting it to just seem dim) and red led (PG14) when a USB packet is received from computer. It also will echo same packet with every byte within it increased by one back to computer.
Now, on PC side the easiest way I found was to use HID API library. As proper precompiled DLL for that was almost impossible to find so I included DLL (release build with visual studio 2013 directly from HID API sources) in zip too, but no other sources for PC side application as my test is based on ancient Borland C++ Builder 4 which you very likely you do not have; this also is the reason I had trouble with DLL as compiling the HID API DLL with that BCB was way too difficult (luckily I had some help). However, examples provided at HID API site should be easy enough to adapt for your preferred compiler though. (and I just realised that .lib file is not included there either, d'oh, as BCB lib will not work with other compilers... Well, I hope you will manage anyway) (and if you absolutely want to have the BCB project, drop me a line, I'll upload that too)
On some usage details;
Relevant (and somewhat modified) files from STM libraries are all placed in usblib directory, and main usb file is usb.c. In your main you only need to included usb.h and call usbInit(). To send packets use usbSend() function and on receive side you'll need to re-implement usbReceiveHandler() function to do your own processing. See comments here for further details.
Packet size is fixed to 64 bytes (1 byte report ID + 63 bytes user payload) so trying any other packet sizes will not work (read: will result an error) unless you change the report descriptors in sources. I've tried to add relevant comments here and there to make it easier to adapt it for your use but I expect it will take some studying anyway.
This is primarily for USB OTG HS (MicroUSB connector) on Discovery board with LCD, hopefully it will work on models without display too, as pin setup in usb_bsp.c is quite hardcoded for this setup (and actually will not work for any other type of interface as I've very likely broken other #ifdef branches in the process).
Tilaa:
Blogitekstit (Atom)