Hi Singapura,
Great to hear your story on the book.
My father looked into publishing a book last year and, like yourself, found it to be a very expensive exercise when paper format is chosen. I applaud your determination to continue through to a final paper based release.
eBook format would likely make the book far more accessible and affordable for many users BUT you have the issue of piracy to consider. sad though it is, there are many who will steal your book rather than pay you a fair sum for your efforts. eBooks make this a very easy theft unless you employ appropriate protection in some form. I am not enlightened on how an eBook is protected but presume there are ways that it may be done. For info, an eBook would be my first choice if it lowered the cost of ownership as I just retired
With regard to file size, 50MB is not unmanageable in many countries these days. My Logic analyser software that I updated last night was 70MB in size. In this age of downloading films across the internet, file sizes have increased greatly and in many countries fast broadband makes them a relatively quick download event.
With regard to my reverse engineering capabilities, like yourself, I have been forced to teach myself and work out how best to approach the problems that are inevitable when undertaking such a challenge. I enjoy repairing equipment and reverse engineering designs as they are like a puzzle that needs to be solved....some people do crosswords and SUDOKU to challenge their mind, I do electronics repair and investigation
With regard to the sample case that I mentioned, namely the thermal camera, I had a great incentive to succeed in reverse engineering the PCB. The camera is an AGEMA (FLIR) PM570 and it was new in its case. It had been found faulty when a warehouse was cleared and was likely a customer return. I paid £1000 for it but its original cost was $56000 from FLIR
As it was mint, I was determined to repair it and keep it for myself rather than attempt to sell it on for profit. When you want to repair something for yourself I feel there is even greater motivation to succeed
Some background on the FLIR PM570 thermal camera.... this was the first FLIR uncooled Microbolometer thermal imaging camera to market and was a flagship model. It is built to last and put up with abuse. A truly superb design that has become a firm favourite in industry. It has a 320x240 resolution and 60fps refresh making it suitable for all manner of civilian and non-civilian uses. The camera was so popular that it was upgraded with faster processors and better microbolometers throughout the long PM series 'reign' I own examples of all generations (1 through 3).
When I first opened the camera I was pleasantly surprised by its well designed clamshell format that positioned the two main boards in opposite halves of the case, with flexible ribbons between. Unlike some designs you did not end up with a pile of PCB's falling out on the bench when the case was opened ! Initial impressions of the PCB's was Oh Dear, high levels of integration and custom VLSI. I was, however, wrong. The unit contains two independent computers. One for the whole system management and one for the image processing required to tame a microbolometer. Both PCBs were in fact populated with the common commercial products of Motorola, Altera and Cypress and not custom VLSI. The overall system management board appeared the likely cause for the fault which was 'Failure to boot'.
I contacted every FLIR service agent that spoke English in an attempt to gain any information on the AGEMA/FLIR thermal camera inner workings and boot sequence. All were sworn to secrecy under FLIR NDA's and ITAR restrictions on design information release. I found one who was willing to give me a tiny bit of help and some price quotes for parts. He advised that the problem was either the power supply module or the LiCO board (MC68340 based system control). This sounded plausible. The LiCo was most likely and would cost £5000 + fitting + programming the OS into flash + camera calibration (essential as cal data resides on this board) The total cost.... likely to be around £7000
As the engineer said..."you buy a Mercedes, you pay Mercedes spares prices". The engineer was not allowed to supply me with ANY technical details, not even the expected voltages coming out of the power supply module ! He did talk to me in general terms though, which is more than I can say for all the other service agents around the world. He explained that the service centres just identify and replace PCB's, then do calibration. They do no component level repair and I doubt that the chap even had schematics beyond PCB interconnection diagrams and voltage / waveform test points for diagnostics.
So with regard to repairing the faulty LiCo board, I was definitely on my own. As I stated, I created a BoM and tracked down the datasheets for every chip used on the LiCo. I had not worked on a MC68000 based computer before but knew the normal basic tests that may be carried out on any embedded computer. I did the usual checks on power supplies, clocks, address & data busses, and specific control/flag lines. The MC68340 was in HALT due to a critical error and that was all that could be determined.
I bought books on MC68000 series embedded computer design and studied its operation and design principles. Its a pretty smart processor and the MC68340 is just a MC68000 with some addons for interfacing to the outside world and memory. After thoroughly studying MC68000 architecture I purchased an old Atari520 ST to on which to practice logic analyser based diagnostics. It was very easy to create a HALT condition
In truth I did not really need the ATARI computer as I was also cutting my teeth on the LiCo board to see exactly what was happening where and when. I had the full service manual for the ATARI 520ST though and that was helpful. It became clear that I needed to reverse engineer the whole LiCo PCB as there were many possible causes of the HALT condition. A key pint to note is that the LiCo board would not work unless all other boards were connected to it (an important point that will be explained later)
I started reverse engineering the LiCo PCB by first placing the board on a photocopier and enlarging the image onto A3 paper. This gave me an excellent view of the PCB component identifiers and also visible tracks. It was a 6 layer PCB though
My colleagues at work saw my A3 images and when told what I was intending to do, said, "you are mad....just give up on it and chuck the camera in the bin" ! Such a negative attitude
I had an advantage over them though.... many years of component level repair experience. They just saw a PCB packed with tiny components, I saw a PCB with many interconnected blocks that interact and form a sort of code that just needs to be unravelled. Nothing to be scared of. You just need to deal with it logically and in small sections to prevent yourself becoming overwhelmed
I had lots of the large A3 images so that I could scribble notes on them etc. Very handy.
For me the next step was to take all of the knowledge that I had gained from the datasheets, application notes, books on MC68000 computer architecture and the Atari 520ST schematics to connect all the various chips together in my own configuration, guided by logic. It isn't that hard as thankfully computers normally contain the same basic elements and have similar needs in order to work. I will not bore the readership by detailing all of them. I ended up with a block diagram/schematic that had all of the chips on the LiCo board interconnected in a logical manner that would form a viable computer.
It was then just a case of using simple tools to confirm expected interconnections between chip pins, and where the expected interconnection did not exist, finding where it went instead. That may sound easy but it is not when you are dealing with FPGA's. They act as Glue logic connecting many different ICs together in a unique fashion. Much time was spent working out which chips were servicing, and being serviced by, the FPGA's. The Wavetek SF10 was invaluable in this exercise as I could quickly work out which FPGA was involved with a chip pin that I was investigating. It did still take many evenings of work under the magnifying glass though !
I ended up with an accurate schematic of the IC interconnections and overall block diagram of the whole LiCo board
Once seen in this format it was not daunting at all and I restarted my investigation into the failure to boot.
Now the killer blow..... I could find no reason for the LiCo board to not boot. I even fitted new SMD DRAM just in case it was some weird RAM issue. No, still no boot. Now remember I mentioned that the LiCo would not work unless all other boards were connected to it ? There is a good reason for that. The LiCo effectively checks that all boards are present and operational as a sort of limited initial self test. Well what was actually happening was that the LiCo was not receiving a correct response from the other computer board and so it went into critical failure (HALT) mode and stopped the Boot sequence before it got properly started. The MC68340 would attempt a restart but fail on HALT. I had been chasing a fault on the wrong PCB
In my defence, as I had no access to technical info on the start sequence or camera firmware, I was not to know that the MC68340 was checking on the other computer and expecting an 'OK' response. As far as I was concerned the MC68340 would boot and report any issues with its video processor board. That was not the case at all.
SOOOOOOO back to square one..... an embedded computer that fails to boot, but this time it was the video processor and not the LiCo ..... more reverse engineering
Fortunately the video processing board is nowhere near as densely populated as the LiCo. It is a dedicated image processing unit so has a relatively simple architecture. The bad news was that it contained three huge >250 pin FPGA's
Each was programmed at boot but could in itself prevent correct boot, that would HALT the LiCo board ! There were also some key communication and data lines running between the LiCo computer and the video processor. Each needed to be identified and its ability to cause a HALT condition assessed.
Long story cut very short, I reverse engineered the video processing Board with little difficulty as it was a basic embedded computer design, just with specialist I/O. It has its own SRAM and Flash ROM so is independant of the LiCo for booting purposes. It was not booting because a 74ALS244 buffer that sits between the CPU and one of the FPGA's had a failed gate. The FPGA's were not being programmed and the CPU was stuck.
A new $0.50 74ALS244 was fitted and the $56000 camera was fully operational
This task took many weeks and much dedication as I was doing it in brief sessions after work in my evenings. It would have been far better to dedicate a decent period of uninterupted time to the task as the human mind can tune into the design and not need to 're-learn' it after a break.
All good fun and I got a real thrill out of getting the camera to boot correctly after a long period of fault induced sleep. She's a beauty and I shall be keeping her.
I attach some pictures of another of my cameras... the PM575 which looks the same as the 570 in all but colour (the 570 is black). The open case images are from a PM695 that I was working on. Note the clam shell design and flexible interconnects between sides.
As you can see, I like my hobby
Best Wishes
Aurora
Home
Help
Search
Login
Register
