The following documentation is based on the BTL Specified Tests revision 5.0 concerning MS/TP testing, which can be found in section 2.2 of the document, BTL Specified Tests-5.0.final.doc. I am not including the section numbers here because, as of this writing, the TI-WG is working on getting these tests included in an upcoming addendum for inclusion in 135.1.

First, a disclaimer. PolarSoft, Inc. is my employer. The opinions expressed here are my own and may not reflect those of my employer. The explicit mention of a product or company in this post is not an endorsement of that company or product.

Test Tools

Oscilloscope

The BTL uses the PicoScope, but I found it pricey and overkill for what I needed. It’s also a bit too bulky to carry in your laptop bag.

The oscilloscope I use for EIA-485 testing is the Logic by Saleae. It’s considered an entry level oscilloscope, but it’s got the features I need for this type of testing: it’s small, lightweight, equipped with easy to use probes, supports time measurements, and has a built in serial analyzer (with auto baud support). It’s powered via USB and small enough to carry in your laptop bag.

Another good manufacturer of USB oscilloscopes is USBee. Again, probably a bit pricey for this type of work and I think the Saleae Logic works just as well.

Serial Analyzer

In my opinion, a good MS/TP analyzer is capable of automatically and precisely measuring the time between the end of one frame and the start of another and is also capable of measuring the time between the start of one frame and the start of another. At a minimum, it should be capable of time stamping the start of each frame with one millisecond precision.

The obvious choice, for me, is BACtrace™ by PolarSoft. However, there are other choices. The BTL uses “Visual Breakout” or “Fronline Serialtest”. From what I can tell, these tools require manual decoding of the MS/TP frames and they only measure intra-octet timing — not intra-packet timing. Wireshark also includes an MS/TP analyzer which I have used for decoding MS/TP frames but I’ve found the time stamps to be imprecise.

For purposes of this document, I will be using BACtrace as the serial analyzer.

Any of these tools require an EIA-485 adapter. I recommend the B&B Electronics USOPTL4. It’s powered by USB and it’s small enough to lug around in your laptop bag. It’s capable of performing at all of the MS/TP baud rates including 76800.

Test Setup

The oscilloscope tests require access to the EIA-485 hardware on your device. How you make this available is up to you, but I recommend soldering leads to the RX, TX, and TX enable (TXE) pins for easy access to this data.

Tests

Verify Tpostdrive

This test requires the use of an oscilloscope with access to the TX pin and the TXE pin on the EIA-485 hardware. The test is used to determine how long it takes the TXE pin to be deasserted after the last stop bit is transmitted. This is measured in bit times, so it’s baud rate dependent. If it takes the device longer than 15 bit times (or 15/baudrate) to return the TXE pin to idle, then the device fails this test. Here is the waveform showing a passing result:

T2 marks where TXE is deasserted and T1 marks the last stop bit transmitted. So, T2-T1=Tpostdrive. The Logic software is capable of calculating the difference between these two markers, and the result is shown below:

This shows that Tpostdrive is 19us. This test was run at 76800 baud therefore a passing result is 15/76800 or 195us.

Verify Tframe_gap

This test requires the use of an oscilloscope with access to the TX pin on the EIA-485 hardware. This test is used to measure the idle time between octets being transmitted by the device. Again, the results are based on bit time, but in this case a maximum of 20 bit times (or 20/baudrate). Here is the waveform showing a passing result:

T1 marks the end of the 0×55 stop bit, and T2 marks the start bit of the 0xFF octet. And the calculated results:

A passing result at 76800 is 260us, and 14.9us is under that limit.

Verify Tturnaround

This test requires the use of an oscilloscope with access to the RX, TX, and TXE pins on the EIA-485 hardware. This test is used to measure how long a device waits to enable it’s transmitter after it’s received any data. Again, the results are based on bit times, but in this case it’s a minimum of 40 times (or 40/baudrate). If the device enables its transmitter within 40 bit times of receiving any data, then it fails the test. Here is the RX to TX waveform showing a passing result:

T1 marks the end of the trailing edge of the last stop bit of the RX frame. T2 marks the point where the device enables its transmitter.

The difference is 4.471ms, which is greater than the 521us minimum required at 76800 baud.

Also, in my experience, a device should wait Tturaround between transmitting data to allow “single buffer” implementations time to process the previous frame. Here is the TX to TX waveform showing a passing result:

T1 marks the point where the device disables its transmitter. T2 marks the point where the device re-enables its transmitter.

The difference is 1.344ms, which is greater than the 521us minimum required at 76800 baud.

This is the end of part one of this post which only examines the tests requiring the use of an oscilloscope.

That quote is applicable in BACnet committee work as well as anywhere else. When proposals get written and before they’re reviewed by the committee, the original authors may not be in a position to continue championing the proposal. This happens from time to time, and when it does, the committee will look for volunteers to take up the mantle.

Such was the case for WS-033. The gist of the proposal is to mandate when and where wildcard values may or may not be used within date and time values. For example, the local-time property of the device may never contain a wildcard value because it represents a single moment in time.

Some years ago, (Bill says it was about 10) Bill Swan began a proposal to point out and clarify these issues. As Bill said, the proposal languished for face time as more important issues were discussed and resolved. When the time finally came to discuss the issue in depth, Bill decided he had too much on his plate and I volunteered to continue working with the proposal. The effort involved was to go through the standard, examine each use case for dates and times, and add clarifying language for each of those use cases. A lofty task, and I can only hope I did it justice and stayed within the original intent of the proposal. I think that’s the case, because Bill “blessed” it when the time came to send it out for public review. However, if it weren’t for Bill’s initial work on this task, the proposal would likely have not reached this point.

Fast forward to the end of the public review period and there were some extensive comments. Some requiring subtle, but important changes. So, the addendum will have to be revised and go through another round of review before it becomes published. I’ll do what I can to aid in that effort as well.

But, these days, my plate is also pretty full considering the work that’s going on in the IP-WG with IPv6 support (that’s “only” a new data link layer and one new object type) as well as the work within the MSTP-WG. Oh, right, not to mention my day job!

The morning of these meetings is usually a little “slow”, and I say that with all due respect. However, getting everyone on the same page with the network setup, then introductions, review of the agenda and minutes from the last meeting, waiting for folks to get coffee, etc. takes up quite a bit of time. Then we dive into various updates from liaisons to other SPCs with ASHRAE as well various “sister” organizations such as IEIEJ. After that, we hear from the various working groups (essentially “focused” subcommittees) about their work. These activities usually take up the 8 AM to 11 AM time slot.

Today, there were a few interesting developments in the working group portion of the meeting.

1. The SSPC formed a new WG, the Elevator Working Group (officially dubbed “EL-WG”). The goal of this group will be to find ways to implement BACnet in the elevator world. It turns out that in the elevator world, they use several proprietary protocols that are structurally similar to BACnet. Our friend “BACnet Bill” Swan will be heading this working group. Congratulations, Bill!
2. This is the first ASHRAE meeting for the IT and SG working groups. The goal of the IT-WG is to find and address areas where BACnet can be integrated with the Information Technology field. The goal of the SG-WG is to find a way to integrate the Smart Grid initiative with BACnet (or vice versa).
3. OK, this one is a cheap plug. Roland Laird from Reliable Controls has decided to step down as convener of the IP-WG. It was officially announced today that at the end of these meetings, yours truly will be the new convener of this group. The goal of this working group is to oversee the use of BACnet over IP networks (BACnet/IP). Roland has been the convener of this group for as long as I’ve been involved with BACnet. There have been several improvements to the BACnet/IP data link layer under Roland’s watch, and I can only hope to fill his shoes.

We spent the time leading up to lunch discussing a clarification concerning the modification_date property of the File object. The question was what the value should contain in the event that the device cannot determine the time from its local_time property. The only way that this can happen is if the device doesn’t “know” how to calculate the current time. Some embedded devices do not contain a real-time clock and are unable to determine the actual local time without the clock being “set”. They may be able to sync their time via some external source such as NTP or the BACnet time synchronization services and keep time (accurately or inaccurately) rom that point, though. However, at boot time, the OS does not know what the actual time is. Consider the case where the battery on a PC motherboard dies. At that point, the BIOS clock is unable to save the time across reboots. So, the PC is unable to determine what time it is from the hardware clock. In this case, when my program gets the current date and time from the OS, it will report its epoch time. Of course, I can set the time to whatever I want.

This is analogous to when an alarm clock is first plugged in. It resets it’s time to 12:00, but after a minute goes by, it’s 12:01. It’s wrong, but the clock still tracks time.

The point of all this is that a device has some default time, and in operating systems this is referred to as the epoch time. Really, this is the point in time when the clock is all zeroes. In BACnet, this date is 00:00:00 on Monday, 1-January-1900.

The question is what should the value should the modification_date property contain when the internal “clock” is in this state. If, for example, you device creates a file at startup then that file object’s modification date must contain the date and time that the file was created. So, my assertion is that in this scenario the property value should either be 00:00:00 1-January-1900 or the epoch date and time reported by the OS.

After lunch and well into the afternoon, we spent our time discussing various addenda. But, that’s a story for another time.

As I understand it, there are two camps when it comes to alarm and event generation in BACnet. That more than one camp exists shows that the standard does not provide an adequate overview for the functionality. If the committee experts are split, imagine how end users feel.

Camp 1 is of the thought that event generation requires a certain “object tax” in that it requires Notification Class and Event Enrollment objects in order to perform event generation at all. As David points out, not only do alarm generating objects have to support NC objects, but those NC objects need to have writable recipients, and more than one based on current BTL requirements and tests. This is a heavy burden to pay for a small sensor device. Small is a relative term considering Moore’s Law, but it’s still a big burden on a device with limited resources. The implication here is that in order for a device to even determine that it is in a state necessary to generate an event, that the device MUST support these object types. So, if a device doesn’t have these objects, then the required STATUS_FLAGS and EVEN_STATE properties remain static all the time. This point of view is supported by the various Alarm and Event BACnet interoperability building blocks (BIBBs). This is the “subscription approach”, in which a client must subscribe to the device in order to receive events from that particular device. The most common use case is a workstation that’s present 24/7 would add itself to a device’s recipient-list in order to receive events.

Camp 2 is of the thought that event generation can be *really* simple and that a device simply need to support the STAUS_FLAGS and EVENT_STATE properties. The values of these properties are then used to indicate whether or not the object is in a bad state. These properties can then be read at arbitrary times to determine if the device needs attention or not. This is the “polling approach” where a client could simply read these properties in a device and make a decision based on their values whether a device is in a bad state. The tax on the server device is much lower because all it has to do is update its STATUS_FLAGS and EVENT_STATE properties. Using the polling approach allows “alarm proxy” functionality which is akin to slave proxy functionality. One con that came up during the meeting is that this approach doesn’t scale well. Perhaps, as it was only briefly discussed, that may be true. But, I’d like to think the committee is an intelligent bunch and can find a way to get this approach to scale.

Personally, I’m not sure which camp I support. I can see both arguments, but I also don’t see in the standard where the “subscription approach” is mutually exclusive from the “polling approach”. It’s possible that the BIBBs imply this, but in this case I think the intent is just as important (if not more so) than what the standard says at the moment. But, this is just my humble opinion. 135-2008 is huge, and it could be that I’ve missed key phrase that others are seeing in Camp 1. It would not be the first time this has happened.

I do like the idea of an alarm proxy, though. Not as an “out”, but as a way to pay a lower tax for event and alarm generation and consumption. There are vendors out there who want to take the much simpler “polling approach” to avoid paying the object tax and I don’t blame them at all. The concept of an “alarm proxy” device would hopefully allow this.

We, as a committee, would have to create a new BIBB (or set of BIBBS) that indicate this functionality. This not only allows for interoperability for this functionality, but also allows end users a way to specify what they want.

The working groups usually meet for 3 days and the main SSPC meets for 2 days.

Today was the first day of the meetings. I decided to attend the BTL-WG meeting and David attended the LA-WG (lighting application working group). This made sense because I’ve been active with the BTL-WG for a lot of years. Also, David has been spearheading a lot of the effort in the LA-WG along with Steve Karg.

BTL stands for BACnet Test Labs, which is a part of BACnet International. The test lab is currently managed by Duffy O’Craven, who has been a fellow BACneteer for about 10 years, which is also about how long I’ve been working with BACnet – so Duffy and I have definitely chewed some of the same dirt.

The BTL-WG is near and dear to my heart, because that’s the group I originally started working with when I first joined the BACnet community. These days, the working group meetings are pretty civil, but I remember a time when that was not the case!!! Those days still bring a smile to my face.

We’re currently on our lunch break, but we were able to accomplish quite a bit this morning and we certainly jumped in with both feet.  We discussed a few clarification requests. All of these documents have yielded interesting conversations. The most intense of which has been a conversation of the functionality checklist for the new Trend Log Multiple object. The problem with (what I consider) “complex” objects is that some of them allow the use of ANY datatype as a value. The ANY datatype unfortunately allows all of the primitive BACnet types ALONG with all of the complex types as values. Most of the time, though, only a small set of the data types really make sense for a particular object, though. For instance, in the case of trending, how often will you trend an object-identifer whose value will (well, should) never change. So, in the checklist we were discussing how to list the optional datatypes supported for the trend log multiple. Limiting the datatypes supported is a good thing for interoperability, IMHO.  It’s because a client device, hopefully, will know what to expect when requesting data from a server device. 

A lot of times, during these conversations, I try to visualize the functional use case for the particular thing we’re discussing. Determining use cases for these things is an acquired skill and sometimes it’s quite difficult to keep up with the conversations if these use cases aren’t on the tip of your tongue. It takes a lot of processing power to listen and digest the information being passed around at a rapid fire pace and it can be very exhausting. It’s a good thing there’s a steady supply of coffee available!

I’ve also taken on a work item for one of the MS/TP tests, which deals with the max-info-frames setting in a device and what can be expected to be sent from an MS/TP device based on the value of this property.

Tomorrow is OS-WG, AP-WG, XML-WG, and the TI-WG.

Of particular importance to me are the IT-WG, IP-WG, and SG-WG meetings on Sunday since the IPv6 work we’ll be doing in the IP-WG will likely be heavily discussed and debated ad nauseum.

The only problem I encountered was that they required my title at JANDAsoft. JANDAsoft (aka JANDA Software Company, LLC) is a sole proprietorship LLC, which is a really just a fancy way of saying it’s a company with one employee – me. So, technically, I’m “Founder and President”, but those titles are entirely too formal for my liking. But, ASHRAE requires a title, so I listed myself as “President”, which is why it’s listed as such on the list of vendor identifiers. It could just as easily say “Coleman Brumley, Grand Poobah“.

Anyway, I’m now officially listed as a BACnet vendor.

If you’re considering building a BACnet product, please obtain a vendor identifier. Oh, and buy your stack from PolarSoft!

This got me to thinking. What impact this will have in the BACnet community?

Addenda 135-2008q, which introduced Zigbee as a BACnet data link layer, was approved in January, 2009. What will Bluetooth 4.0 mean for BACnet/Zigbee, or more generally wireless BACnet? My brief introduction (from the press releases) about Bluetooth 4.0 leads me to believe they’re trying to directly compete with Zigbee.

I think a lot of the same concepts (virtual MAC layer, caching, etc.) that apply to BACnet/Zigbee would also apply to BACnet/Bluetooth.

This is an interesting time in BACnet. With the work being done in IPv6 and the hope to work with the Smart Grid alliance, the committee has their work cut out for them.

At the time, I had considered that normal and didn’t think much of it. I was “happy”, or at least that’s what I kept telling myself. In reality, I was miserable! I was in constant pain. I could hardly walk. My back hurt continuously. And those were the symptoms I knew about. What I didn’t know, and I would only find out during testing for the surgery was that my body was slowly turning on itself. The surgeon, Dr. George Eid, described it as “malignant obesity“. My BMI was over 40, and I was in the very early stages of having kidney problems (determined by a microalbumin test). I had “severe” obstructive sleep apnea.

Well, I’m happy to report that today that’s all gone! To date, I’ve lost 110 pounds. I’m exercising again (though not as regularly as I should) and eating better. I still, occasionally, slip into bad habits but I do my best to keep an eye on myself. My Type II diabetes is gone — 100% cured. My HA1C is around 5. I sleep without a machine now!

Some other “stats”:

• 14 inches gone from my waist (size 56 to size 42)
• I went from a XXXL to an XL shirt.
• My original wedding ring no longer fits. My wife bought me another for Christmas, though!
• I can now fit in a Herman Miller Aeron size C chair without voiding the warranty.
• I can fly without asking for a seatbelt extension, nor risking getting charged for a second seat.
• I can put the tray down in front of me on a plane. I could NEVER do this before.
• I can buy clothes at Wal-Mart. No more Casual Male Big&Tall for me.
• I’ve not drank soda (diet or otherwise) for over a year. I’ve taken a sip here and there, but can’t stand the taste of it now.

   

1.  Download the latest BusyBox. These instructions are based on BusyBox v1.13.0.
2.  Run make menuconfig, and select all of the options you want built into BusyBox. Remember to setup your cross compiler!
3.  Run make.

In my case, I’m not using devpts, so I manually make the pseudo terminal (pty) entries in /dev. I used the following script to do this:

for i in 0 1 2 3 4 5 6 7
do
    /bin/mknod /dev/ttyp$i c 3 $i
    /bin/mknod /dev/ptyp$i c 2 $i
done

Also, I made sure that CONFIG_FEATURE_DEVPTS was not set in the BusyBox .config before running make. The devpts file system was not configured in my kernel, so I knew I didn’t want it in BusyBox either. As far as I can tell, telnetd is the only BusyBox module that relies on this setting.

Some say that telnet is dead due to security issues and we should used ssh/scp instead of telnet/ftp. If you’re in that camp, I’d urge you to check out dropbear. However, for what I’m doing with this board, easy remote access trumps complicated security measures. Of course, your mileage may vary (YMMV), and I’m not advocating ignoring security concerns altogether.
     

For example, here’s an image of some code from Visual Studio 2005. You’re welcome to hate me over the color settings. Cie la vie. I’ve heard them all, too.

Here’s that same code pasted directly into this blog post:

xmlDocPtr getdoc (char *docname)

{

xmlDocPtr doc;

doc = xmlParseFile(docname);

if (doc == NULL )

{

        return NULL;

}

return doc;

}

Ugh. Since I regularly email code snippets to people, this requires manually editing the code after it’s pasted into an email message or Word doc or whatever.

Paste Special allows you to choose from RTF or unformatted text or unformatted Unicode text. However, “Paste Special” isn’t really helpful here because it pastes the text with a white foreground, which isn’t particularly useful on a white background.

Here’s where I catch up with the times. Turns out, Visual Studio has these cool things called macros. Never heard of ‘em! Why, in my day, we did everything by hand in our IDE. And it snowed both ways, uphill. And we liked it. Or, something like that.

Anywho, macros. As is usually the case, I’m not the only one bothered by this nuisance. It’s just I’m the only one who didn’t go looking for a code solution. I just kept editing the code by hand. And I liked it. I liked it so much; I did it several times a day. Up hill, both ways.

I don’t know what got into me, but today I’d finally had enough. I went looking for a solution.

This link will take you to Jeff Atwood’s solution. Go ahead, read it now. I’ll wait here. Jeff points out that VS copies text to the clipboard in Rich Text Format (RTF). This is supported by the “Formatted Text (RTF)” in the Paste Special choices. Jeff wanted to copy HTML from VS to paste into web pages or text boxes. I just wanted plain text. So, I expanded his macro a bit to do what I wanted. I added a function, RTFtoText that strips all of the RTF tags from the copied text and leaves the line breaks and tabs intact. There’s probably a more eloquent solution, but this works for me. I didn’t bind the macro to Ctrl-C yet, so I still have one extra key stroke or mouse click. I’ve mapped the CodeToText macro function to Alt+C in the text editor, so my key combination is Ctrl+C and the Alt+C. Then I can go to Outlook or Word or whatever and Ctrl+V. Way easier than Ctrl+C, go to Outlook, Ctrl+V, then highlight the new text remove the background color. Rehighlight the new text and change the font color to black.

So, I figure that one key stroke will save 30-40 seconds per instance. That adds up after a while. It’s worth the time it took me to work on this, which was a couple of hours or so.

Here’s the sample shown pasted into an email message after applying the CodeToText macro:

I was going to show a sample here after running Jeff’s RtfToHtml, but it doesn’t quite get it right for C source. I’ll have to spend some time on that later, but for now this does exactly what I want for emails.

Download the FormatToHtml macro (6kb)

After that success, I started playing with all of the Sample macros provided by Visual Studio. Some of the more useful ones I found were the ones that added comments (AddFunctionDescription, AddRevisionMarks, etc.) and navigated to places in the code (BeginningofFunction). I modified AddFunctionDescription and AddRevisionMarks to add block comments formatted the way I like them. I also copied BeginningofFunction and created EndofFunction from it. Vim has the same browsing features, and I’ve found these quite useful. I’m glad there’s an equivalent in VS. I also added a macro that adds a comment to the end of the selected line. I do this a lot and I figure this macro will shave a couple of seconds from that activity.

I feel sad that I’d not found macros before. Of course, I knew they existed but I’ve never played worked with them. Now, I’m glad I’m did, and that I didn’t just keep doing things like we did in the old days. Up hill, both ways.