2011-12-22, 15:00 CET
HomeWork: Ordered a long list of electrical installation material, because the whole electric system needs to be re-built. I have found completely molten components in the lighting installation (will post a photo one day), so there's enough motivation to tackle this...
2011-10-23, 18:00 CEST
HomeAutomation: After some time taking care of the "home" part in home automation, I have now implemented a firmware protoype for the digital input module (HA-P01). Testing will require building the hardware prototype as well, though...
2011-08-06, 15:00 CEST
HomeAutomation: Changed USB/CAN controller's firmware so that the two buses can be powered on an off (also added support for this in ha_iod), and added support for the two power LEDs (the green ones at the CAN connectors) while I was at it.
Test mode places the CAN controllers in loopback mode now, writes a test message (an ONBUS message) and waits for its return - only then loopback mode is disabled. This solved a problem with the CAN controller back in normal mode again before actually sending the test message, and waiting forever for an acknowledgement (due to the currently empty bus). So loopback testing now also works for both bus controllers. While coding in that are, I also enabled the CAN traffic LEDs (the yellow ones) to be lit during CAN transmission processing - however, this currently only works for incoming datagrams... Sending out packets should also be indicated by blinkenlights.
2011-08-04, 00:10 CEST
HomeAutomation: Finally got to debugging the HA-B02.01 board, and found no code at all running on it - after disabling the microcontroller's JTAG interface (through the respective fuse), though, this started to work. USB communications works. Powering on and off the CAN buses (i.e. switching the relays from software) works as well. Testing the CAN controllers in loopback mode was also successful. Testing the whole CAN line through the transceivers is still an open task, but requires another bus device to prevent being caught in retransmissions and error modes due to missing acknowledgements.
2011-08-02, 21:30 CEST
HomeAutomation: The new USB/CAN interface does not quite work as I expected when conducting a first test: While it is properly recognized as USB serial device, I cannot communicate with the microcontroller through that serial line - there is just no response. Debugging of this must wait until tomorrow.
2011-07-31, 22:00 CEST
HomeAutomation: Finished the HA-B02.01. The !USB_RST issue was caused by a falsely sorted resistor - I put in 47 kOhm where 4.7 kOhm should have been - red and orange may be easy to mix up... So that's sorted out now, too.
2011-07-30, 22:45 CEST
HomeAutomation: Further populated the HA-B02.01 board, and successfully tested the USB part of it. Somehow, !USB_RST is not sufficiently asserted by hardware on connection to the USB host as I originally intended - this must be further analyzed and should be addressed. If that's not possible, I can still manage it in firmware, because the microcontroller can set this signal as well.
2011-07-29, 23:30 CEST
HomeAutomation: Started populating the HA-B02.01 PCB. First, soldered parts of the USB subsystem - getting the FT232 down is the most tricky part of this board, as it's the only SMT IC. I will finish this tonight and test it before putting the other components in place...
2011-07-27, 20:00 CEST
HomeAutomation: Received the HA-B02.01 PCB from production. This needs stuffing and soldering now...
2011-06-01, 20:00 CEST
ThiemosProjects: I am adding little icons to certain sections on this web page, indicating the state of the respective item within a project:
means that the item is in a usable state for development at the current stage, not neccessarily in the final state for the finished project 
means I am evaluating what I have done so far, and testing whether this item is usable the way it has been made. Issues found are fixed in this process. 
is work in progress - yet to be brought to some usable state 
is something just not there yet, there may be thoughts and plans, but not much actual work has been done on "blank" items.
This whole colour-coding, though, not neccessarily makes this whole collection more usable for any reader, but hopefully helps me keeping an overview about where I stand with which part of larger projects...
2011-05-30, 00:30 CEST
HomeAutomation: Besides cleaning up the appartment, I have spent the weekend doing some testing of more parts to be used in this project (mostly the quad optocouplers and relays), re-designed a small part of the USB/CAN interface (due to the relays being not one- but two-coil variants), and fiddled around with the PCB design and routing of the USB/CAN interface and the 16-port digital input board. Both are still unfinished...
It looks like I could get the digital input board done in one layer, which would mean I can produce it myself rather than having it fabricated (for ~50 EUR per board). The USB/CAN board, though, will need to be made in a PCB house, most probably with solder mask and (that will not cost that much more) silkscreening.
2011-05-28, 00:45 CEST
HomeAutomation: Spent another evening on the HA-B02 USB/Dual-CAN interface PCB layout. There's still a handful of signals left to route, but after five hours, I just cannot concentrate on it any more. %)
2011-05-24, 00:40 CEST
HomeAutomation: After some bugfixing, I am now able to send CAN datagrams from hashell, travelling through the TCP, ha_iod, USB, HA-B02, and into the CAN controller which, in loopback mode, sends them back up the stack. As the shell does not listen for incoming datagrams, the way up ends in ha_iod, which can correctly parse the received transmission:
ha_iod[4752]: sent CAN msg type "m" addr "810" (bus 0, devid 42, mtid 6, devnr 0), length "2", data[0] = "1" ... ha_iod[4752]: received CAN msg type "n" addr "810" (bus 0, devid 42, mtid 6, devnr 42), length "2", data[0] = "1"
The device number ("devnr" in the above debug output) is not needed for sending and therefore not calculated in the sending codepath - on receipt of the message, this is calculated from bus and device identifications. The debug function logging this prints only the first byte of data, but the second one is also here, as seen in the raw TCP protocol that ha_iod sends around.
2011-05-21, 13:15 CEST
HomeAutomation: Changed communications protocol between USB/CAN interface and control PC in the PC->CAN direction - needed to rework the construction and parsing of CAN datagrams according to HomeAutomation/Parts/HA-I05. Unfortunately, I cannot test it right now as I am travelling by train.
2011-05-20, 00:35 CEST
HomeAutomation: Implemented and tested the changed protocol between USB/CAN interface and USB host. Works now, device is identified correctly, and a test CAN message is correctly received and interpreted by the host software.
2011-05-19, 00:30 CEST
HomeAutomation: Tested the ha_iod functionality in communicating with the USB/CAN interface. Character drops and data corruption was observed. Re-designing the protocol spoken over USB-serial, and changing the firmware and ha_iod software accordingly.
2011-05-15, 17:50 CEST
HomeAutomation: USB/CAN converter firmware works now for sending and receiving CAN datagrams through SPI (with the CAN controller in loopback mode, because I don't have a second CAN device yet) and identifying remote transmit requests (RTRs) - currently, it can send itself a test datagram with RTR set, remove that bit, and send it back to itself. During this, the datagram's contents are correctly interpreted and displayed through the USB connection.
2011-05-15, 02:30 CEST
HomeAutomation: Working on the USB/CAN converter firmware. Talking to the MCP2515 seems to work now: I can initialize it and send messages to it, which afterwards reflects in the controller's status flags. However, configured in loopback mode, I don't receive the messages I send out, nor do I see the CAN interrupt signal being asserted...
2011-05-11, 00:15 CEST
HomeAutomation: Breadboard prototype of HA-B02 (actually only the very basic components, MCU, CAN controller and a FT232 development board) constructed and programmed with the HA-P04 firmware development version mentioned before. USB communications work, as well as parsing the transmissions received over USB. CAN controller initialization fails, though, the test read of one of the configuration registers returns something different from what I programmed into it. If I continue to use the CAN controller anyways, I seem to get no valid replies and read from it continuously... I don't quite know why, but this also blocks USB communications - this should not happen, as CAN communications does not happen in interrupt context here...
So, two issues to investigate: Why does my SPI communication with the MCP2515 fail, and why can this block USB?
2011-05-05, 23:30 CEST
HomeAutomation: Wrote development version of the USB-to-CAN interface firmware. Now the really next step is building the breadboard prototype to see if this works the way I planned...
2011-04-28, 00:25 CEST
HomeAutomation: Finished USB/CAN interface design - next step with this is building a test setup (on solderless breadboard), and see if it works the way I planned. Time to dig out the started test circuit mentioned on March 09 again...
2011-04-22, 15:30 CEST
HomeAutomation: Currently designing the USB/CAN interface schematics. Looks like this will be one of the more complicated devices I have done so far, featuring two CAN buses that can be powered on and off by software.
2011-03-09, 23:00 CET
HomeAutomation: Working on two things currently: On the hardware side, I am prototyping (on breadboard) the USB/CAN bus interface, on the software side, I am planning and programming the ha_iod which will service this interface hardware on the control PC side.
2011-02-11, 09:00 CET
GPIBtoUSB: Finally took a photo of the stuffed board, I am currently using it without an enclosure. Therefore, I'll mark the project as finished for now... Seems to be okay the way it is.
2011-02-08, 22:30 CET
HomeAutomation: Now that GPIBtoUSB is quite out of the way, I am now trying to write down some plans made so far. As this project seems to be a larger one, making plans seems to be a good idea before actually building something.
2011-02-02, 21:10 CET
GPIBtoUSB: Stuffing of ordered PCB is completed, device tested and found to work even when talking to a Python (plus pyserial) installation on my Windows lab machine. So far, I use the board without enclosure... Looking for a case is hard when the PCB is already done, but I just could not wait for that before designing and ordering the board.
2011-01-18, 16:00 CET
GPIBtoUSB: Ordered a double-sided PCB for the final device.
Older entries
Last year's news are in ProjectsBlog/ProjectsBlog2010.
THIS DATA IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS DATA, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
All product and brand names mentioned on there pages and in the source code are registered names and/or trademarks of the respective owner and are mentioned for identification purposes only.
For a full copyright notice, please see this link. For imprint and contact information, please see http://www.thiemo.net/.