The Lighting Applications working group met for a couple of days, and crafted responses to the public review comments for our Lighting Output object. We also got the draft for the next pubic review done, and it should be reviewed with only substantive changes. Good news for this object that has been in the works for many, many years. We also crafted public review responses for the Channel object and the WriteGroup service, and drafted a subsequent review document.

Coleman, Dave, Dana, Don, and I ate at the Tin Drum restaurant for lunch. Delicious!

The BACnet meetings were again held in the spacious Georgia Tech Technology Square Research Building.

I brought a WattStopper DLM setup for the BACnet International Plugfest, held at the Westin hotel in Atlanta.  It’s always fun to have bright lights controlled by a BACnet universal dimmer!  I presented a workshop on the work that the Lighting Applications working group has been doing, with some tips for developers.  It was titled “New BACnet objects and services have been proposed to support lighting control. What can you do with them? What can you do to prepare your devices?”

I received one of the awards (although I wasn’t in Las Vegas), which was really unexpected.  The full list of recipients is listed on the BACnet International “Leaders of the Pack” website press release.

Pete Baselici was at the awards ceremony, so he received the award for me, and presented it to me when he returned.

I have always enjoyed being around Bill. We had lots of things in common – photography, BACnet, microcontrollers, politics, family, and religion.  Twice a year we met together at BACnet meetings at the ASHRAE meetings over a weekend, and Bill would always be searching out a local Anglican church to attend, while I sought a Catholic church.  Twice a year we met during the week for BACnet interim meetings, usually in Germantown and Atlanta, and enjoyed the local food. We would compare photography ideas and equipment stories, talk about putting BACnet into tiny devices, and discuss elections and local politics.  We often talked about his family – his wife Kathy, and his daughters and how they were doing in school.

Bill was a prolific writer, and wrote the BACnet Bill blog and the Continuing Home blog.  He wrote numerous BACnet tutorials and articles.  He wrote numerous BACnet proposols (at least 89) to create new objects and services, or fix problems in BACnet, and collaborated on many more.  I recall Bill as ever the international collaborator, bringing needs from other countries into our BACnet committee.  I remember when Bill took over the BACnet Chair from Steve Bushby, and how he moved from being a timid leader, to running the BACnet meetings with confidence.

The BACnet committee and working groups are a small bunch of unique individuals, and any single contributor would be missed.  But Bill will be missed not just for his contributions, but for his friendship, creativity, and gentle nature that he brought with him.

My flight to San Francisco from Birmingham went through Houston.  In Houston, I got to ride the Automated People Mover train between concourses, always a highlight on my trips since I worked on these vehicles at several airport and downtown systems for Westinghouse Transportation Systems from 1992-1997.   The train performed flawlessly – perfect programmed stop, smooth acceleration, and very little jerk.  Much to my delight, San Francisco Airport also had Automated People Mover trains, and they also worked very well to get me to the rental car garage.

The BACnet meetings were held at the The Pacific Energy Center in downtown San Francisco.  We discussed the Property_List property for objects, the Zero Config algorithm for MS/TP MAC addressing, and the You-Are service for address and device ID assignment. More importantly, we celebrated Cinqo de Mayo at Chevy’s.

On Thursday I arrived at the Embedded Systems Conference a little early, and got to meet Jeri in her motion activated Light Emitting Dress before her talk. After the keynote, I toured the exhibits and picked up several new development kits from microcontroller vendors. The nice surprise was to see my STM32 Challenge contest entry displayed at the STM exhibit. I didn’t win, but I had fun.  The STM32 Design Challenge entry was just a simple port of my BACnet Protocol Stack to the STM32F103 ARM Cortex M3 XL-Density Performance Line microcontroller with 1 MByte of embedded Flash and 96K SRAM. I also created a printed circuit board to attach to the STM32 Discovery Kit so that I could integrate RS-485, LEDs, and a DIP switch.

BACnet MS/TP

Plugfest with Delta Controls

TimeSync Decode Noon

BACnet Services

Today, after launching the menu and seeing no interfaces (again), I decided to search the Internet and find a better way, and found two things of note. The first method, which I found posted on Ubuntu Forums, is the manual way of configuring Wireshark to run as a normal user (with admin group privileges) by configuring only dumpcap to have the elevated privileges:

$ sudo apt-get install libcap2-bin wireshark
$ sudo chgrp admin /usr/bin/dumpcap
$ sudo chmod 750 /usr/bin/dumpcap
$ sudo setcap cap_net_raw,cap_net_admin+eip /usr/bin/dumpcap

The second method was outlined in Ubuntu Bug #513903 at Lauchpad and can be done with Ubuntu Lucid and beyond. It creates a new group “wireshark”, configures dumpcap with setcap, and requires the user to manually add themselves to the “wireshark” group (then log out and log back in to activate it).

$ sudo dpkg-reconfigure wireshark-common
$ sudo adduser skarg wireshark
$ exit

Don’t do both methods, as they are slightly different solutions.

One of the proposals that started in the MS/TP working group made it through the public review process, and was voted by our committee to be published!

The Journey of a Small BACnet Proposal

In typical bike shed fashion, a small change to the BACnet standard took a very long time to become a standard.  Here is the story.

In November, 2002, I proposed (my 13th proposal) to expand the allowable baud rates for MS/TP to include 57600 bps and 115200 bps.  When reviewing MS/TP in Clause 9, I noticed that the baud rates specified in 9.2.3 are rather limited, and the fastest one doesn’t work well on PC based UARTs (76800 bps).  Since PC based control was becoming more prevalent in 2002, it seemed appropriate to permit fast speeds for PC compatible UARTs.

Someone reviewed the proposal, and asked for some data regarding the maximum length of an RS-485 segment while running at 115,200 bps.  I searched for the best literature I could find on the subject, and ended up with an Application Note from National Instruments which contained a nice graph of Cable Length vs Data Rate for RS-485.

Unfortunately, there was not a table of data along with the graph. I found and quickly learned how to use Scilab, the free platform for numerical computation. I did some linear interpolation (curve fitting) based on points (red dots) from the graph (Scilab Script):

-->// Scilab 3.0
-->// data from the graph
-->// The data is linear, but the graph is logarithmic
-->t = [0.1 0.2 0.4 0.5 0.8 1.0];
-->y = [4000 2000 1000 800 500 400];
-->xyd = [t;y];
-->yi=exp(interpln(log(xyd),log(t)));
-->err = (y-yi)'
err  =
1.0D-12 *
!   0.4547474 !
!   0.2273737 !
!   0.2273737 !
!   0.1136868 !
!   0.1705303 !
!   0.1136868 !
-->tt = [0.1 0.1152 0.2 0.2304 0.4 0.4608 0.5 0.8 1.0];
-->yi=exp(interpln(log(xyd),log(tt)));
-->xyi = [tt ; yi]'
xyi  =
!   0.1       4000.     !
!   0.1152    3472.2222 !
!   0.2       2000.     !
!   0.2304    1736.1111 !
!   0.4      1000.      !
!   0.4608    868.05556 !
!   0.5       800.      !
!   0.8       500.      !
!   1.        400.      !

Since the graph was logarithmic, the points had to be converted.  Scilab took the points (t,y), created a table (xyd), interpolated (yi), checked the error of the curve for each point (err).  Then I added some standard baud rates to the list of points (tt), and did the same interpolation.  The result is the table (xyi) which includes .1152 (baud rate) at 3472.2222 feet.  I de-rated and used 3280 feet (1000 meters) as a safety margin.

I compiled the information into a revised proposal, and submitted the information to the working group in October, 2004.   At the April, 2005 Germantown meeting, the MS/TP working group voted this proposal up to the BACnet SSPC for review and future publication.

The document was discussed again at a subsequent MS/TP working group meeting in 2006, with concern raised over the reduced distance for the higher baud rate.  A consensus vote decided to eliminate 115,200 bps as a possible rate, leaving 57,000.  I revised the proposal to that effect in April, 2006, and it was voted up to the full SSPC BACnet Committee for review and future publication.

In October, 2008, there was a discussion of MS/TP baud rates on BACnet-L mailing list.  Coleman indicated that:

I’d like to get a proposal together that rewords the baud requirements in clause 9 of 135.  We’ve discussed 115200 several times in the MS/TP-WG, but I’m thinking something a little less contentious like making 38400 the default and making 9600, 19200, 57600, 76800, and 115200 optional.

Coleman sent a note to me indicating that he had modified the proposal again, mandating that 38400 be a default baud rate in addition to 9600.  I checked the venerable “BACnet Document Status Summary” which indicated that my proposal was still in MS/TP working group instead of SSPC.  Bummer.  It had been sitting around for years due to some missing communication.

I wrote to Coleman and said that I would prefer to leave my original proposal in the SSPC-135 queue as-is since it is more likely to be adopted sooner than later as it is now 3 years in the queue – and a case can be made that it has been sitting there awhile.  I suggested that another proposal with the additional mandatory baud rates would be better or could be discussed along with my proposal in the SSPC-135 meeting and added prior to a public review vote by SSPC-135.

My proposal finally made it to the floor of the Atlanta BACnet committee meeting in November, 2009, at the very end of the meeting.  After a short discussion, Coleman’s proposal was suggested to replace mine.  As meeting time was running out, David Fisher, convener of the MS/TP working group, “passionately insisted that [Coleman's proposal] will get a due amount of serious discussion time in Orlando. This proposal has been delayed unreasonably for years now.”

Coleman’s proposal was discussed at the next SSPC meeting in Orlando in January, 2010.  After a brief discussion and a minor revision, the proposal was voted to Publication Public Review as Addendum 135-2008ab. The pubic review period lasted from March 26 to May 10, 2010.  It received 2 comments requiring resolution, and 4 supportive comments (which do not require any action to be resolved).

One of the supportive comments suggested that we consider changing MS/TP timing delays when using the 115,200 baud rate in order to provide the fastest possible throughput when using the new speed.  It was decided to consider this request, and some analysis was done.  When we met in Abuquerque, in June, 2010, the analysis was presented as “no significant speed improvements could be made by changing the time delays.”  The BACnet committee voted to approve the public review comment responses, and since there were no substantive changes to the addendum, it is now published as an addendum to the BACnet standard.

I created a BACnet Development Kit, compiled the open source BACnet Protocol Stack hosted on SourceForge.net firmware using gcc-avr, and attempted to load the firmware onto the kit using an Atmel AVR ISP mkII USB programmer.  I connected the AVR ISP mkII to my Ubuntu Hardy Linux PC and attached the 2×3 ISP cable to the development kit board, and attempted to program using avrdude:

$ avrdude -c avrispmkII -p m644p -P usb -e -U flash:w:bacnet.hex

avrdude: usb_open(): cannot read serial number "error sending..."
avrdude: usb_open(): cannot read product name "error sending..."
avrdude: usbdev_open(): error setting configuration...
avrdude: usbdev_open(): did not find any USB device "usb"

Wow! That wasn’t nice.  A search on the Internet turned up some answers about how to fix the problem, and I modified my /etc/udev/avarice.rules file to look like this:

SUBSYSTEM!="usb_device", ACTION!="add", GOTO="avarice_end"

# Atmel Corp. JTAG ICE mkII
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2103", MODE="660", GROUP="dialout"
# Atmel Corp. AVRISP mkII
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2104", MODE="660", GROUP="dialout"
# Atmel Corp. Dragon
SYSFS{idVendor}=="03eb", SYSFS{idProduct}=="2107", MODE="660", GROUP="dialout"

LABEL="avarice_end"

I disconnected and reconnected my AVR ISP mkII, and tried again.  I still had the same results.  I checked that I was a member of the dialout group:

$ groups
skarg adm dialout cdrom floppy audio dip video plugdev users fuse lpadmin admin

I looked at the symbolic link in the /etc/udev/rules.d/ directory and also consumed the README file.  My file had the following name:

/etc/udev/rules.d/z60_avarice.rules

So I changed the filename:

$ sudo mv /etc/udev/rules.d/z60_avarice.rules /etc/udev/rules.d/60-avarice.rules

I unplugged the AVR ISP mkII, and plugged it in again.  I tried to run avrdude again:

avrdude -c avrispmkII   \
     -p m644p -P usb -e        \
     -U flash:w:bacnet.hex

avrdude: AVR device initialized and ready to accept instructions

Reading | ################################################## | 100% 0.01s

avrdude: Device signature = 0x1e960a
avrdude: erasing chip
avrdude: reading input file "bacnet.hex"
avrdude: input file bacnet.hex auto detected as Intel Hex
avrdude: writing flash (57406 bytes):

Writing | ################################################## | 100% 6.31s

avrdude: 57406 bytes of flash written
avrdude: verifying flash memory against bacnet.hex:
avrdude: load data flash data from input file bacnet.hex:
avrdude: input file bacnet.hex auto detected as Intel Hex
avrdude: input file bacnet.hex contains 57406 bytes
avrdude: reading on-chip flash data:

Reading | ################################################## | 100% 5.41s

avrdude: verifying ...
avrdude: 57406 bytes of flash verified

avrdude: safemode: Fuses OK

avrdude done.  Thank you.

The kit programmed successfully, and began operation.

In April, 2008, I was informed that the Cimetrics U+4 packets showed up in Wireshark, but were not decoded correctly.  I asked for a sample of the capture, and reverse engineered the header.  I then created the BACnet MS/TP decoding in Wireshark in order to display the MS/TP data, and passed the BACnet Network Layer and Application Layer information along to the existing dissectors.

The beauty of the BACnet protocol is that it is layered.  The NPDU (network layer) and APDU (application layer) encodings are the same regardless of the datalink layer used.  The NDPU layer is decoded by packet-bacnet.c, which passes the APDU layer to packet-bacapp.c.  The BACnet MS/TP datalink layer is decoded by packet-mstp.c which I created, and passes the NPDU, if it exists, to packet-bacnet.c, for decoding.  The ARCNET, Ethernet, and BACnet/IP (packet-bvlc.c) all pass a relevant packet to packet-bacnet.c for BACnet decoding.  I created packet-cimetrics.c for the Cimetrics header which passes the BACnet MS/TP datalink layer to packet-mstp.c.

The BACnet MS/TP patches were accepted into the Wireshark repository on May 13, 2008, checked in as SVN 25291.  The SVN 25881 was a fix to the Length decoding.  The BACnet MS/TP decoding eventually made it into the Wireshark 1.1 development release, but is not present in the Wireshark 1.0 stable release.

Wireshark now sees packets with the Cimetrics U+4 signature encapsulated in the SNAP protocol as MS/TP packets, and it is able to open a file that has been saved in PCAP format using the MS/TP WTAP signature.  But I didn’t have a Cimetrics U+4 device.  So I used a standard RS485 converter, my open source BACnet stack, and wrote a simple application to packetize the MS/TP frames and saves them to PCAP format.  I could now capture MS/TP packets and view them!

In August, 2008, I received an email from John in New Zealand.  His intention was “to use an existing simple VB application that captures MS/TP traffic from a low cost USB to RS-485 converter, to send the MS/TP packets using Winsock/UDP to Wireshark for final dissection and display.”  I figured that we could do this by making use of the existing SNAP protocol dissector that I created for the Cimetrics packets.

I reused the code that I had written to save in PCAP format, and wrote a simple application to packetize the MS/TP frames and resend them on Ethernet as the Cimetrics U+4 signature encapsulated in the SNAP protocol.  I got it to work under Linux, but would probably need to use WinPcap to get it to work under Windows.

Sending those SNAP protocol packets on Ethernet allows the display of BACnet MS/TP packets in realtime alongside BACnet/IP and BACnet Ethernet.  This makes it very easy to relate traffic going to and from workstations and routers with what is happening on the BACnet MS/TP network.

There are some sample captures (see cimetrics_mstp.pcap and mstp_wtap.cap) that demostrate some of the abilities of Wireshark.

I use a USB to RS-485 converter from SerialGear USB-COMi-SI-M, and am told that the B&B Electronics USOPTL4 works very well.  I am also told that the USB to RS-485 adapters that use the FTDI chipset are great for this as they allow the use of 76800 baud which is usually the stumbling block for native MS/TP interfacing with a standard PC serial port.

I drove to the BACnet meetings in nearby Atlanta and Bill photographed my license plate.  We need lofty goals, don’t we?

The BACnet committee met in Salt Lake City at the end of June.  We had a large number of Addenda that had finished public review, and had lots of comments for which to respond.  Salt Lake City had some interesting sites and some street items that I had not seen before.  The “Look” on the pavement, as well as the flags used at some crosswalks.

I attended Mass at Cathedral of the Madeleine on Saturday night.  It was a beautiful church and a thought provoking sermon.

I ate some wonderful food in Salt Lake City, including a fabulous carrot cake at Squatter’s Pub Brewery, and some delightful salmon at Cucina Toscana.

We had our traditional Tuesday night BACnet dinner at Dogfish Head Brewery.

Most of the working groups met.

1. Figure out how to do BACnet segmentation
2. Figure out how to get BACnet MS/TP into libpcap/winpcap.
3. Add a couple of BACnet dissector enhancements to Wireshark.
4. Learn about using Wireshark for problem network analysis.

I attended Laura Chappell’s training sessions, and learned a whole lot about Network analysis and the love-hate relationship between TCP/IP SYN, ACK, and Keepalives (#4 completed). I also wrote some Wireshark code during the classes which I promply submitted (#3 completed). Loris came into the activity center and sat down with my son Joshua and me, and so we discussed how to integrate BACnet MS/TP RS485 from serial port into libpcap/winpcap (#2 completed). On the last day and the last session of the conference, I attended a session by Richard Sharpe about file sharing protocols and learned about Wireshark conversations (#1 completed).

We were treated to an inspiration talk on Tuesday morning by Vint Cerf. After the talk, I went to Laura’s session, and Joshua talked to Vint. Vint signed Joshua’s Half-Life player guide, had photos taken with Vint and Gerald, and the Wireshark crew gave Joshua some swag.

Gerald treated the developers to dinner on Tuesday night at Trader Vic’s. I drove to dinner with Joshua and Jaap Keuter, and learned about PBX systems and Jaap’s passion for skydiving. At dinner I sat next to Ulf Lamping and learned about yet another division of Siemens and about Ulf’s love for motorcycle riding. Guy Harrris and Mike sat across from me.  Joshua ate with Gerald’s wife and daughter, and John Bruno’s wife.

The Foothill College campus was beautiful and on Spring Break. The food was awesome and plentiful.  The people were great!  The Wireshark sessions were helpful.  Maybe I will get to attend next year.

The Transmit Complete (TXCn) Flag bit is set one when the entire frame in the Transmit Shift egister has been shifted out and there are no new data currently present in the transmit buffer. The TXCn Flag bit is automatically cleared when a transmit complete interrupt is executed, or it can be cleared by writing a one to its bit location.

I had initially written the code to clear the TXC0 flag by clearing it, rather than setting it. Since the code could not determine when the end of the transmission occurred, I had added a _delay_us() function from the AVR-GCC library. This is what the AVR-GCC manual says about that function:

In order for these functions to work as intended, compiler optimizations must be enabled, and the delay time must be an expression that is a known constant at compile-time. If these requirements are not met, the resulting delay will be much longer (and basically unpredictable), and applications that otherwise do not use floating-point calculations will experience severe code bloat by the floating-point library routines linked into the application.

Severe code bloat indeed! I had used a non-constant (the Baud Rate) in the delay call, and that resulted in a 4k increase in code size. After fixing the Transmit Complete flag functionality, I was able to remove the _delay_us, and the code size dimimished by 4k. On this 16k device, that means alot!

Statistics for the BACnet Stack at SourceForge on the ATmega168 are as follows:

IAR Atmel AVR C/C++ Compiler V5.10A/W32
10 191 bytes of CODE memory (+ 36 range fill )
775 bytes of DATA memory (+ 24 absolute )

avr-gcc (GCC) 4.2.2 (WinAVR 20071221rc1)
Program: 12052 bytes (73.6% Full)
Data: 481 bytes (47.0% Full)

With all the extra code space, I went on to add more functionality to the demo. The BACnet capabilities include WhoIs, I-Am, ReadProperty, and WriteProperty support. The BACnet objects include a Device object, 10 Binary Value objects, and 10 Analog Value objects. An LED is controlled by Binary Value object instance 0. All required object properties can be retrieved using ReadProperty. The Present_Value property of the Analog Value and Binary Value objects can be written using WriteProperty. The Object_Identifier, Object_Name, Max_Info_Frames, Max_Master, and baud rate (property 9600) of the Device object can be written using WriteProperty.

After adding all that functionality, I learned the hard way about the C-Stack differences between the IAR AVR compiler and the GCC-AVR compiler. The IAR compiler uses a fixed CStack size. If it is not set correctly, the CStack can overflow and cause problems in your code.

The GCC compiler uses the RAM not allocated to variables and text for the C-Stack. That means that the data value reported by the avr-size program is only part of the picture. If the data value is 481 bytes, and the device has 1024 total, then 1024-481=543 bytes are used by the C-Stack. In other words, don’t be fooled by the “47% Full” printed by avr-size and think that you have extra RAM. You might be able to add some more functionality, but certainly leave some RAM (or alot in my case) for the C-Stack. The GCC-AVR has two intrinsic variables for tracking the C-Stack: _end and __stack. These can be used to paint the C-Stack prior to its usage, and monitor the C-Stack during runtime. I added this technique to the demo.

The final statistics on ATmega168 demo of the BACnet Stack at SourceForge:

IAR Atmel AVR C/C++ Compiler V5.10A/W32
12 732 bytes of CODE memory (+ 36 range fill )
955 bytes of DATA memory (+ 24 absolute ) (CStack=0×200)

avr-gcc (GCC) 4.2.2 (WinAVR 20071221rc1)
Program: 15790 bytes (96.4% Full)
Data: 414 bytes (40.4% Full) (CStack=0×262)

Note: The photos are ancient computer memory from The Computer History Museum in Mountain View, California.  I’m visiting the area for the Wireshark Sharkfest ’08.