wxWidgets strange modal dialog crashes

Recently, I wrote one program with Code::Blocks version 12.11 and wxWidgets version 2.8.12. Logic of the program required invoking modal form (inherited from wxDialog, created with wxSmith). Once, during debugging, I found that the program continiously crashed after showing this modal form. The crashes usually occured either just after constructing of this dialog instance, or after a few seconds of this dialog being active. I revised all places in the source code which were somehow related with construction of this dialog, and with passing parameters of its construction and initialization. But I was unable to find any error(s) in the source code itself. At last, I got a flash of inspiration: I actually created this dialog from secondary ("worker") thread. After reimplementing this fucntion as running in the main thread (via combination of auxiliary window, SendMessageW with WM_USER and pointer to the structure with function parameters packed into WPARAM message argument, and MSWWindowProc functions), all crashes stopped. So the error was not in some line of the source code itself, but in the wrong architecture and lack of attention to this fact. The accompanying factor was that in previous version of the program, I used simple standard wxMessageBox function in that place. wxMessageBox apparently invokes WINAPI MessageBoxW function, and this works fine from secondary thread. But when I changed this to invoking of custom wxDialog form, in order to gain additional functionality, crashes began, and it took some time for me to understand where the problem resides.

Android-powered Tablet PC for reading books

A few days ago, I bought MoveO TPC-1VX Tablet PC (in Russian) with Android 4.0.3 on board. It features 7" multi-touch 800x480 screen, 4 Gb of built-in flash memory, 512 Mb RAM, and other characteristics are on the line of other devices in this price sector. I wanted low-cost handheld PC mainly to be able to read books (PDF, HTML, and other standard formats). It is much more convinient to do this on 7" than on 3.6" screen. It even fits into pocket of my sleeveless jacket. By far, I have not observed any bugs or software freezings. Maybe one day I will write a program for Android platform. At last, Android today is the most popular OS for mobile devices.

P.S.: well, I already have bicycle and Tablet PC. The only thing left to buy is reflex camera, and I will completely fit controversial folklore image of a young programmer :)))

Radio-controlled all-wheel drive Robot based partly on Arduino modules

Today I have attended Chaos Construction 2012 (in Russian) - computers and computer graphics, 8-bit music and demo scene annual festival. For me, one of the most interesting things there was presentation of all-wheel drive radio-controlled robot made partly based on modules from Arduino open-source electronics prototyping platform.

Robo-hobby blog (in Russian) is the official current webpage of these guys (those who are working on a robot, not those who develop Arduino). If you will ever want to learn anything about relatively easy-to-reproduce hand-made radio-controlled robots based on open-source hardware & software components, I would advice to check this blog. Authors share their experience about working on such a project. This is really interesting, even for me, professional electronics developer. I've already added RSS feed of their blog into my feed reader.

Broken WM_DROPFILES (Drag-and-Drop) functionality in Windows 7

Yesterday I spent at least one hour in finding and fixing cause of error due to which in one of my applications Drag-and-Drop functionality did not work in Windows 7 OSes, as was thankfully reported by one user. The reason traced to be that Microsoft decided to disallow applications to receive certain types of messages which are related with inter-process communication. This was done to enhance system security, of course. WM_DROPFILES is one of messages which are now not working by default. Now you need to explicitly tell OS that you want to receive and process this message, via calling appropriate API function: solution for problem with WM_DROPFILES in Windows 7. It is not difficult to call one more function during program initialization, but I'm really tired of various problems which arise from incompatibility between different Windows and Office versions. In this aspect, development for microcontrollers appeals to me much more, since there you can control everything, and tested procedures will not unexpectedly stop working because of some changes in underlying OS logic. I'm speaking here about MCU hardware+software projects where OS is still not necessary, (i.e., not high-performance high-cost complex monsters) and so you have some confidence in all parts of the system.

Dummy bicycle lanes in Moscow

This summer, I was in Moscow for a few hours, walking through the city while waiting for my train. My attention, among other things, draws to the fake (dummy) bicycle lane on prospekt Vernadskogo, near the "University" metro station. This "bicycle path" is actually one metre wide green band drawn on the pavement. The problem is that people do not regard it as a road for bicyles - instead, all pedestrians treat this piece of asphalt simply as part of pavement, and behave accordingly. Everyone who will try to move on this path on bicycle with a speed more than 15-20 km/h, will inevitably bump into someone else (pedestrian) during the first minute of trip. So this "bicycle lane" is absolutely useless, this is essentially just a mock-up. Even more, it is not only useless, but harmful for all cyclists. This is because if anyone wants to cycle with reasonable speed here, right solution would be to move in traffic area of this prospekt, in the first traffic lane, near the border. But Russian road laws states that cyclists should move through the special "bicycle lane", if there is one. So if any cyclist would bump into another object (car, bus, or pedestrian), while moving on traffic area of this prospekt, one could say that this happens because of he/she do not abide this particular rule of road laws. Shame on those who were responsible for this fake "bicycle lane".

Reanimating NiMh Battery Pack in home cordless phone

At home, we have cordless "TELECOM" phone. This summer, after two weeks of idle time during our vacations, it refused to continue working. It also refused to charge its pack of 3 NiMH batteries (T160 600 mAh 3.6V D4 marking). I.e., green LED which should indicate chraging process and presence of phone tube on the base module did not turn on when I tried to start charge the cordless receiver by putting it to its place (its dedicated socket). I tried to apply the same method I used for my LiIon smartphone battery (see my previous post on it): firstly to charge battery directly via lab DC power supply. The difference is that this pack of 3 NiMH batteries does not have internal built-in charge controller, so there is no need to disclose internal connector pins. I set up output voltage to about 4 Volts, and max. current to about 50 mA. After approximately 2 hours, power supply switched from constant current into constant voltage regulating mode, and I disconnected the battery. After placing this slightly recharged battery back into cordless phone tube, and putting this tube back on base station, green LED which indicates charging process, turned on, and device continued to work in normal mode. Apparently, charge controller built into this phone tube needed for its operation higher voltage than discharged battery was able to deliver. So be aware of this method, and do not throw out your battery prematurely.

UPD: the same method works with NiMh AAA accumulators, I've just checked this today. 900 mAh acc. battery discharged to ~0.7 volts has been charging with ~90mA current for a few hours, after that I was able to complete the process with standard charger.

P.S.: Caution! In absense of temperature monitoring circuit, do not charge the battery with currents more that 0.1*C, for example, in my case I had battery with 600 mAh Capacity (designated by capital "C" letter), so max. safe charging current was 60 mA. Also, do not try to repeat this without proper setting of output voltage limit in your power supply. Put the battery into protective box for a period of charging to prevent damage from its possible explosion. Make sure that you are ready to quickly disconnect the power supply and to extinguish a fire in case if it will arise.

Bugs in Windows Application Development

Today I at last have found time to fix some long-lasted bugs in one of my programs. Some of these bugs have been annoying users for about one year. They inconspicuously appeared after some phase of editing of source code. During fixing, I found two other previously completely overlooked bugs. They are not critical in nature, but annoying. It seems that this process (of finding and fixing bugs) can last forever. Development for Windows OS, comparing to development for microcontrollers, allows you to employ many ready-to-use system (as well as third-party) libraries, thus freeing you from the task of implementing service code for yourself, but at the same time, bugs and inconsistencies in system and third-party libraries can force you to spend much time in efforts to figure out why your application is not behaving as you expected, and I'm pretty tired of it. Conclusion is to test as big fraction of program's functionality as possible after every source code change.

Bicycle off-city trips

A week ago, I had joined a bicycle club, and took part in two off-city trips, during weekend, -- about 100 km distance each, with 20-25 km/hour (up to 30) average speed. These were not competitions, but nevertheless they gave some physical load, and after them, sleep is deep. I plan to continue such trips. I hope that such physical exercises will increase my overall productivity and feeling, and give some energy. Aside from this goal, Saint-Petersburg's suburbs are very beautiful in nature, and have strong historical meaning and trace.

How to reanimate Li-Ion or Li-Pol battery from your smartphone

Today I want to share my experience in repairing the Li-Pol smart battery in my HP iPAQ 1930. See my previous post on it.. My battery was marked with HP H1910 string on its paper box. The problem with it is if you'll leave device without even a single charge cycle for several weeks, it will discharge to a level from which it is impossible to initiate further recharging. If nominal voltage is 3.7 Volts, and you have allowed to discharge to about 3 V, this is the situation considered. A small piece of electronics, consisting of charge controller IC (integrated circuit), and a couple of power field (MOSFET) transistor keys, is placed between actual Li-Ion (or Li-Pol) battery and the outer contacts. Charge controller IC monitors voltage levels at the battery itself and outer contacts, opens necessary power key transistors, and communicate with host device via SMBus or other protocol to allow it to know state of the battery. Problem with discharging of a battery below certain level is that this controller IC stops working, so it is impossible to recharge the battery, since power key transistor have become permanently closed. But in many cases it is still possible to reanimate the smart battery.

To do this, cut off small pieces of plastic from both sides of the battery, to open access to the inner contacts of Li-Ion (Li-Pol) battery. You should see and have access to two metal stripes after this operation. Get laboratory DC power supply unit, with both constant current and constant voltage, modes of operating. I use SHENZHEN MASTECH HY3005D-3. Constant current mode is indicated by "C.C." red round LED at the front panel, while constant voltage -- by the nearby LED named "C.V.". My battery has capacity of 950mAh. The usual current for charging Li-Ion batteries is calculated as capacity x 0.2 (in the appropriate units, in my case, it would be 950 x 0.2 = 190 mA). Since we want to bypass control electronics, and will not monitor temperature of the battery, it would be safer to decrease this value, I think, two times will be enough, so I assumed charge current of 100 mA. I shortened outputs of one channel of SHENZHEN MASTECH HY3005D-3 power supply unit, and set short-circuit output current to this level. (Be aware also that maximum allowable current that USB port should be capable of providing by its spec, is 500mA. So if your device is charged through USB, do not exceed this value under any conditions. Even safer would be to use half of that value, that is, about 250 mA, as an upper threshold for charging current.) Then I set output voltage to nominal voltage of the battery, 3.7Volts in my case. After this, I connected output of power supply to inner batteries contacts. Initial current will be 100 mA, equal to short-circuit, and "Constant Current" LED should be active. During a few hours, the battery will be charging, after which voltage should rise to its nominal value (3.7 Volts in my case), current drops to near zero, and power supply switch to "Constant Voltage" mode. That's it. Now you can power off power supply, disconnected wires from battery, place it into your handheld device, and continue using it, without having to buy a new battery.

WARNING 1: Do not try to repeat the process without power supply with both "Constant Current" and "Constant Voltage" output mode, and without proper and carefully checked set-up values.

WARNING 2: Li-Ion batteries might fire and explode. It is safer to put the battery into the metal or other solid case during the process to avoid possible harmful accidents.

Simplified English

I have recently stumbled upon such thing as Simplified English. Even for my ears, Russian being my native language, Simplified English sounds rather strange and, well, oversimplified. I read a few sample sentences, and it is clear that all of them lack some part of sense comparing to the original English sentences upon which they were constructed.

It seems that there is no "Velvet Way" or "Silver Bullet" that could solve the problem of communication between people with different native languages worldwide. I did not ever hear about language school that teaches "Simple, or Simplified Language". Just opposite, all of them claim that their method allows one to master English (or other language of interest) to maximum possible level, and this fact clearly indicates that there is no or little demand for learning Simple Language.

My conclusion is that there are no ways, except for long persistent systematic work, to learn any foreign language.

Requiem to Phobos-Grunt

Yesterday, after about two months of orbiting the Earth on an intermediary, low-altitude elliptic orbit, Russian interplanetary station had finally fallen back to Earth, luckily into Pacific Ocean, not on some populated area.

Its short flight raised many questions to Roscosmos and even state's officials. Combined with several other satellite launch failures during last year, these questions are especially vital today. Maybe something in the area of top management of Roskosmos is really going wrong, maybe someone still think that world-class high-tech unique things can be developed for amount of money much less than world market suggests. Maybe something is broken at the bottom end of a technological chain, say poor quality control of production.

But here I want to point to only one side of the problem: nowadays, we have many strong rigorous math instruments that can be used to assess reliability and probability of failure for virtually any piece of hardware and software. Researches in the area of development of error-tolerant and reliable hardware and software systems allow one to employ many scientifically proved methods of designing and testing. This is XXI century, at last.

If scarce funding had really taken place, why main engineers and their bosses who were responsible for device subsystems could not just say: "Hey, guys, this is not enough to achieve the project's goals. You either will give us enough resources (time, money, people, equipment, etc.), or we will not sign for the work.". It seems that something is broken in the whole chain of decision making in Roskosmos. Sadly, but such conclusion came to mind after reading news.

Digital Photo Frame Texet TF-618

Last week, I had have to choose digital photo frame as a New Year gift to my mother. I stopped at Texet TF-618 due to its placement of control buttons at the front panel instead of at the backside. All other devices that I saw, have built-in control buttons made as usual mini-knobs, at the back side of them. TF-618 have just opposite design solution: a series of sensor LED-highlighted buttons at the front, just below its screen. This, I suspect, does not significantly raise its cost, but make usability and feel of control much better. I do know that there is small remote infrared control unit supplied with almost each digital photo frame device, including TF-618, but I prefer to have ability to deal with device without it in case it will be lost or accidentally hidden somewhere.

Attentiveness in engineering work

The day before yesterday I had finally finished firmware in VHDL which is burned into Altera CPLDs in my design. Now all works fine, including surrounding digital schematics.

Unfortunately, I spent about two months on this part of project instead of planned four weeks. The reason is lack of attention during initial schematics development and VHDL program writing. Little logical error in VHDL program and lack of thorough test simulations caused me to solder several wires to key logic nets of the design under consideration, connect them to special debug connector and examine its pins with oscilloscope. Physical layout of the two mezzanine PCBs does not allow to access all logic nets directly with oscilloscope probes. At the end, error in firmware was found and fixed, but at price of extra time and nerves.

After VHDL firmware was fixed, the device still did not function as it should. The reason traced to be a subtle difference in my schematics in comparison with third-party device to which my design should be compatible. My schematics was right, but incompatible with third-party software from manufacturer of that device. This was fixed by means of one 0603 resitor and two equipment wires.

Finally, this part of device passed all tests.

The lesson learned is the impermissibility of neglecting thorough and attentive requirement analysis and creating simulation tests during initial design phase.

Multi-Platform User Interface and GTK+

During last days, I have being working with one program which uses GTK+ 2.22 for its user interface. It works, but some things look as something foreign on Windows XP. In particular, this is strange folder opening dialog, lack of flashing of active modal window title when clicking with mouse on inactive parent window, and some other small things.
My conclusion is trivial: if you target only one platform, it is better to use GUI libraries created for this particular platform that fully complains with established de-facto standards.

Stupid Connector Pinout Problem

Today I spent half of a working day correcting the problem with wrong IDC2-10 connector pinout. The usual pattern in which pins are ordered is as follows:

1 3 5 7 9
2 4 6 8 10

In the User's Manual of industrial PC, to which I must connect, the picture looks like:

1 2 3 4 5
6 7 8 9 10

I was slightly alarmed when I saw it the first time, but I thought that this is their right to re-order pins on their own module. Today, when I tried to get my PCB and this third-party industrial PC to work together, it was revealed that pins on its socket are actually ordered in a usual way, as shown in the first block. The unusual order that I observed in the manual was result of mere inaccuracy of their documentation writer. Strictly speaking, this is not my fault, but if I would check the actual ordering of pins before working on PCB, it would save me several hours of my life. Instead, today I have had to do some mounted-wire soldering on all manufactured devices to bring PCB footprints pinout to an actual state.

UPD: They fixed this error in the latest version of the manual. I should had to check for the latest version before using it.

CRM and Electronics/Software Development

In my spare time, I like to read one aviation forum. From there I learned that in the area of civil aviation there exists the whole concept about how members of aircraft flying crew should communicate and behave with each other, in order to achieve the best possible flying safety. I think, that something similar can be adopted to the field of electronics/software command development projects.

Crew Resource Management explanation on Wikipedia

CRM is all about preventing, detecting and correcting (even potential) human errors at the earliest possible stage, thus achieving the best flight results and safety. If you will regard flight of an aircraft as a multi-people PROJECT, you may naturally see that CRM principles can be applied also to electronics/software multi-people development PROJECTS. Unfortunately, I did not hear that even basics of such approach are studied in any university. This leads to very big role of project leader and his personal communication skills in overall success of any development project.
Such dependency could be mitigated, in my view, by working out and accepting concept of interpersonal communication in software/electronics development industry.

In particular, co-pilots are specially trained to correct the captain and to question potentially wrong decisions if it seems appropriate in a given situation. But in the area of electronics/software development, authoritarian project leader often has too much power and possibilities to send a project in totally wrong direction.

Wrong Pin Numbers in PS/2 socket

Today I spent almost the whole working day to make (solder) a few adapters to remedy my PCB designing error. The problem was that I used MINIDIN-6 surface-mount female socket on my PCB, and I incorrectly routed PCB tracks to pins of that socket. It revealed that I used mirrored view of the socket when direct, non-inverted view should be used. Only one additional checking procedure would save me almost a whole working day.

PS/2 connector on Wikipedia

Forms (Windows) Interface Font

Delphi 7, while being very powerful IDE for Windows development, has some deviations from standards set by Microsoft. One of them is that by default, VCL forms use MS Sans Serif, 8pt font for all controls. This may look good on developer's machine, but on some target machines, this may look very bad because of lack of this font and substituting it for some another.
Standard behavior would be to use default OS Dialog font.
To overcome this, in each form's OnCreate event, invoke the following procedure:

procedure SetFormFontToSystemDefaultFont(Form: TForm);
var
  NonClientMetrics: TNonClientMetrics;
begin
  NonClientMetrics.cbSize := SizeOf(NonClientMetrics);
  SystemParametersInfo(SPI_GETNONCLIENTMETRICS, 0, @NonClientMetrics, 0);
  Form.Font.Handle := CreateFontIndirect(NonClientMetrics.lfMessageFont);
  if Form.Scaled then
  begin
    Form.Font.Height := NonClientMetrics.lfMessageFont.lfHeight;
  end;
end;

(Set ParentFont property to True for all controls on the Form for this to have effect).

Delphi Inactive Forms Behavior

In Delphi 7, there is one drawback in VCL, which appears as lack of any indication of which window is active when user clicks with mouse on inactive window. Standard behavior of compliant windows application is to flash the title bar of active modal window in that case, but Delphi forms do not respond to this action.

To remedy this, add the following code to your modal forms:

type
  TMyForm = class(TForm)
  ...
  protected
    procedure CreateParams(var Para: TCreateParams); override;
  ....
  end;
.... 
procedure TMyForm.CreateParams(var Para: TCreateParams);
begin
  inherited;
  Para.WndParent := GetActiveWindow;//to allow title flashing of child modal dialogs
end;

Electronic Component Misorientation Problem

Today the first preproduction batch of my devices, consisting of four PCBs (Printed Circuit Boards), was finally completely mounted, and I began to power them up in order to test the mounting accuracy and device functionality. It was revealed during mounting that I had placed some components too close to each other, although this will not prevent embedded software developers from using the devices to debug their firmware. When I started to bring the live into the device, I found that at one position, on all devices, stabilitrons were mounted in opposite polarity. It seems that assemblers who performed actual soldering, are accustomed to the fact that diodes' Anode pole are usually goes to positive polarity, and Cathode pole - to negative. This is true for simple forward usage of regular and shottky diodes, but stabilitrons need to be used in reverse direction. I marked where the Anode should be on assembly drawing, nevertheless it seems that assembler was guided by datasheet, where Anode mark is showed, and polarity of PCB padstacks. I'm thinking about resorting to using SOT-23 case for this component in second version of a scheme (for those who are not familiar with it: this is 3-leads case, it have 2 leads on one side and one on another, thus it is impossible to place it in wrong orientation). It may be _slightly_ more expensive than currently used 2-leads case, but it will leave us from necessity to think about right orientation and to control it.

It seems, that many engineering decisions are often driven by similar motivation - to ease manufacturing and/or repairing processes, at price of slightly increasing components cost.

It also reminds me that responsibility of everyone who design any type of interfaces, is to make every interface as clean and consistent as possible, and to make sure that working with this interface requires from user absolutely minimum of possible knowledge of a system.

SOT-23 drawing