To be fair ...

Just to be fair, it appears that the serial problems that I was having with the ZigBit module was in part due to the USART mode on my BusPirate.

I was having all kinds of problems running 38400 baud on the 8Mhz RC clock - when I stumbled on the clock variance I figured it was that. I later hooked up a FTDI cable to the serial out on the same ZigBit and got really good communications at 38400b.

It was "Really Good" but not quite "perfect" I was still able to hit the ZigBit with freeze spray and cause problems with the output:


Hello, world 43
Hello, world 44
Hello, world 45
Hello, world 46
Hello, world 47
Hel wor 48
Hellorld 49
Hello, world 50
Hello, world 51
lo, world 52
Hello, world 53
ello, world 54
Hello, world 55
Hello, world 56
Hello, world 57

I was able to drop the clock speed (using fuses) to 1Mhz and run 9600 baud when I used the double speed mode for the USART, but then the module is running pretty slow.  That may be OK for what I need - And 9600 baud may work "perfectly" when running the 8Mhz RC clock, even with the variance.

Also, there wasn't much need for all of the PWM stuff I did two posts ago - you can set the CKOUT fuse and get clock output on pin 42 of the ZigBit module.

ZigBit Clock Speed Quick Update

Just a quick update, Atmel outlines the trim process in this document - They describe a one time calibration process where they do a binary search using a 32khz reference signal to get the correct OSCCAL - then write it into a byte on a EEPROM to use later.

Using the above document, it might (as I suspected) be possible to do this in real time, so that as temperature changes, the clock speed is updated.

Problems with ZigBit serial communications

ZigBit RC Oscillator vs Temp vs Voltage

I've been evaluating the ZigBit modules from Atmel for use in a project I'm working on. I will need rock solid serial communications - I am not going to get that (at least not using Contiki OS, or even rolling my own) unless I do one of two things:

1) run at 1mhz - which I might be able to do - I'm not sure how well the different baud rates will work when running at 1mhz
2) Find some way to automatically trim the RC oscillator
3) Find a way to introduce an external clock - I don't think that this is a possibility.

Let me show why the internal 8mhz RC clock will be a non-starter for most people wanting to use Contiki OS.

First, I did my research and found that other people got things to work, pretty much - for example Here - that post was super helpful, but even after following it, my serial communications seemed, well, flakey.

After banging my head against the wall, I decided to try some stuff out -

Using the hello-world example in contiki, I added the following code to the main process:

(sorry about the image - I was having a bear of a time formatting the code in blogger - and yea, it's pin B7, not B5 as shown in the comments)

All this does is sets PIN B6 to output and sets the pin high (sanity check) and sets pin B7 to be a PWM output at 50% duty cycle - According to the ATMega1281 Datasheet - this should give us a output frequency of the input clock / 256.

(oh, by the way these are labelled as other stuff ---GPIO1 and GPIO2, pins 5 and 6 --- on the zigbit datasheet - I found a translation to the ATMega1281 here.)

I used my BusPirate to read the frequency output on that pin, here is what I got (average) 30844/hz but this is divided by 256, so my actual number is 7.896Mhz - hmmm within the 10% listed in the datasheet, but probably enough to mess up our serial communications, but look what happens when I go and hit it with freeze spray-

AUX Frequency:  autorange 30,852 Hz

AUX Frequency:  autorange 30,877 Hz

AUX Frequency:  autorange 30,875 Hz

AUX Frequency:  autorange 30,870 Hz

AUX Frequency:  autorange 30,626 Hz

AUX Frequency:  autorange 30,275 Hz

AUX Frequency:  autorange 30,134 Hz

AUX Frequency:  autorange 30,095 Hz

AUX Frequency:  autorange 30,043 Hz

AUX Frequency:  autorange 30,047 Hz

AUX Frequency:  autorange 30,012 Hz

AUX Frequency:  autorange 29,986 Hz

AUX Frequency:  autorange 30,020 Hz

Down to 7.676Mhz - you are getting the point.

I tried to adjust the dividers for the serial out in the contiki source, but none of them really got close to the right baud rate with the frequency I had, and even if I did - I might have wildly different temperatures in the environment where these things are going. I would hate to have everything suddenly stop working when it gets to 110 degrees in some auto body shop in Phoenix or something, or say Alaska in the dead of winter.

There is a way to calibrate the oscillator, OSCCAL - I suspect that the BitCloud software has a way to automatically trim the clock based upon the external 1Mhz clock that you can find on pin 10, but I was already thinking about moving on to a different platform - This just gives me that little extra push.

I may play around with the 1Mhz clock yet, but I am thinking about moving to an ARM STM32 paired with a Microchip MRF24J40 - the pair of those will run about half the cost of the ZigBit module, give me more horsepower and more control over the process.

Sigh, I just had to get that all off of my chest.

ZigBit with avrdude and Bus Pirate

Full disclosure, I haven't exactly 'programmed' the zigbit yet, but I do seem to be able to communicate to it with it using avrdude with a buspirate.

I found a few posts on this, but I think there were some errors in them. I wanted to post what worked for me in case it helps someone.

The board is my own breakout board - but all pins listed here are the pins on the actual ZigBit module.

I have the 'seed' cable, and not the 'sparkfun' cable:

I of course have GND and 3.3v hooked up to their proper places -

GND - 9,22,23

3.3v - 24,25 (I use a bypass cap and a ferrite bead as indicated in the datasheet)

MOSI (grey) goes to 38

MISO (black) goes to 39

CS (white) goes to 8

and CLK (violet) goes to pin 1

Unless I'm looking at things wrong (Its late :-) - it is different than what is posted In this post by Atmel.

I am hoping to use Contiki OS on this - I am looking at a post Here.

getent with LDAP on Solaris / openindiana

For the life of me, I don't know what the difference is here, but it seems as if having a profile makes a big difference to how LDAP works in Solaris /OpenIndiana

I was mucking about with things,  I had getent showing all of the LDAP users just fine - I'm not sure what I did exactly, but it stopped working.

My Config file looked something like this:

/var/ldap/ldap_client_file

NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= 192.168.0.14:389
NS_LDAP_SEARCH_BASEDN= dc=***,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=people,dc=***,dc=com
NS_LDAP_SERVICE_SEARCH_DESC= group: ou=group,dc=***,dc=com
NS_LDAP_BIND_TIME= 10

and then I added two lines (one of which wasn't correct!)

NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= 192.168.0.14:389
NS_LDAP_SEARCH_BASEDN= dc=***,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_PROFILE= default
NSLDAP_SEARCH_REF= true
NS_LDAP_SERVICE_SEARCH_DESC= passwd: ou=people,dc=***,dc=com
NS_LDAP_SERVICE_SEARCH_DESC= group: ou=group,dc=***,dc=com
NS_LDAP_BIND_TIME= 10

Magically, ldapclient went to the ldap server and loaded a default profile from some testing I was doing a while ago, then the file looked like this:

#
# Do not edit this file manually; your changes will be lost.Please use ldapclient (1M) instead.
#
NS_LDAP_FILE_VERSION= 2.0
NS_LDAP_SERVERS= 192.168.0.14
NS_LDAP_SEARCH_BASEDN= dc=***,dc=com
NS_LDAP_AUTH= simple
NS_LDAP_PROFILE= default
NS_LDAP_SERVICE_SEARCH_DESC= passwd:ou=People,dc=kms,dc=com

and then getent was showing LDAP users again.
There isn't *that* much difference between the files. Could it be that merely having a profile in the ldap server makes a difference on Solaris?

problem with smbldap-grouplist & friends

I was trying to set up smbldap-tools on a solaris system and I was having some problems, I'm posting this fix in the hopes that it will help someone. I was getting an error about references strict in perl. In the smbldap-grouplist, they were passing a string that kinda looked like an array, but it was still a string. I changed the type to an array, and everything worked.

Hope this helps!

error

ARRAY ref while "strict refs" in use

and then the patch:

129,130c125
< my @attrs=['gidNumber','cn'];
<
---
> my $attrs="['gid','cn'";
132d126
<
136,137c130
<     push(@attrs, 'displayName');
<
---
>     $attrs  .=  ",'displayName'";
139d131
<
143c135
<     push(@attrs, 'sambaGroupType');
---
>     $attrs  .=  ",'sambaGroupType'";
145d136
<
149c140
<     push(@attrs, 'sambaSID');
---
>     $attrs  .=  ",'sambaSID'";
151c142
<
---
> $attrs.="]";
154d144
<
163a154
>
167c158
<                                  attrs => @attrs
---
>                                  attrs => "$attrs"
169d159
<

Emacs Macro & ssh

Recently, I've been trying to customize emacs to do more and more stuff for me that I find tedious.

One of those things is setting up the ssh sessions that I use all the time. Often, it is nice to have them in an emacs session (although sometimes it's a pain, like when you want to run emacs in that session)

Multi-session does a pretty good job, but I was still having to connect to where I wanted to go and then rename the session to reflect where I was (i.e. work, live, etc)

I spent a bit of time one day making a macro for emacs lisp which did everything I really needed (warning, this requires multi-term.el to be loaded)

(defmacro defterm (termname &rest body)
(let ((mytermname (concatenate 'string
                    "term-" termname))
 (intertermname (concatenate 'string
                    "*" termname "*")))
 `(defun ,(intern mytermname) ()
    (interactive)
    (if (get-buffer ,mytermname)
    (switch-to-buffer ,mytermname)
  (progn
    (make-term ,@(cons termname body))
    (switch-to-buffer ,intertermname)
    (rename-buffer ,mytermname)
    (term-char-mode)
    (multi-term-handle-close))))))

After this I can use the same arguments as you would for make-term, except that the first argument is the name of the terminal. So, for example, if I wanted to log into a remote server and then log into another remote server that is behind the firewall, I would call it like so:

(defterm "brutus"
 "ssh" nil "-t"
       "kelly@servera.somewhere.net"
 "ssh" "-t"
       "kelly@brutus.somewhere.net")

This would create function term-brutus that would create a buffer called term-brutus that was logged into the remote machine, or it would find that buffer if it already existed.

If you have a bunch of these, and want to do them all at the same time without
having to call each separately:

. . .
(defterm "bash" "bash" nil)
(defun start-terms ()
(interactive)
(term-greywolf)
(term-live)
(term-postgres)
(term-bash))

As a side note, I discovered while working with this that you can chain your ssh calls in this manner

ssh -t kpm@servera.somewhere.net ssh -t kpm@serverb.somewhere.net

and this would log in to the first machine, call ssh to the second machine and that's what you wanted in the first place. (don't ask about port forwarding doing this, I haven't tried it.)

Hope this helps someone.