Renard Start Address Firmware

[dirknerkle]

This new feature makes a Renard controller addressable. Go ahead, admit it -- you've wanted it for a long time... and now that your tongue is hanging out, I'm pleased to announce that it's a reality. :mrgreen:

Credit goes to Phil Short for his code artistry and to RavingLunatic for some insightful comments in helping with the documentation, which you will find in the Wiki via the Renard Firmware page or by clicking here:

http://www.doityourselfchristmas.com/wiki/index.php?title=Renard_Start_Address_Configuration _Guide

For those of you who are or are soon-to-be Ren-W users, this will be an incredible boost to what you will be able to do wirelessly. In testing, I assembled a nifty 12-controller system simply by broadcasting all channels out from a single Ren-W transmitter; each Ren-W receiver picked up the information and responded only to the channels it was assigned to use. Very slick.

The concept for using it is quite simple, but interested parties are cautioned in the following ways:

1. If you are new to DIY equipment and especially to Renard, get to know how your gear works in normal mode before you jump into this, or confusion is highly likely. Questions are welcomed, but don't expect someone else to figure it all out for you. Remember, this is DIY.

2. The configuration guide probably will answer most questions you might have, so please read it before posting them here. If you find that you do have questions that the guide doesn't address, please post them here or send me a PM. I will try to answer them appropriately and quickly.

[tweist]

The timing is perfect on this new release. I have reviewed the documentation, and yes you are correct, you have to think about what you are doing before you jump in head first. But once you understand the system, it all makes sense. It really make it simple for setting up multi controllers with one global broadcast. This will really help my timing issues over the number of houses we are doing this year.
Thanks to all of you, and a special thanks to Phil, for your hard work and dedication to the wireless world.
Oh and the house count is now up to 14 and may go to 16 by summer.
I like pushing the envelope.

[oldcqr]

Crap! :p:p:p

Well... Ok... Not really. :D:D

One of the things I want to teach myself is PIC code, and one of the things I wanted to attempt was making REN things addressable. I figured I'd get around to it in the summer (I have a client that is working me full time at the moment). You beat me!

That's OK, I have OTHER ideas :cool:

[Reddy_Kilowatt]

Cool Beans!!:mrgreen: Thanks all!

This will sure help with some Channel layout/ordering problems I've had in the past. It completely changes every year.:(


One thing to note, is the default for this firmware is PWM where the default for the regular firmware is Non-PWM.

I appear to be against the norm, but after using Non-PWM firmware for my incandescents in season 1, then using all PWM for season 2.

Season 3, I went back to Non-PWM, as I'm personally convinced that it made the incandescents look brighter.:rolleyes:

-Craig

[BF210]

Good writeup in the Wiki, DN. My thanks to you and the rest of the team that brought this into being. Always good to have options!
(yet another Don)

[ErnieHorning]

I'm personally convinced that it made the incandescents look brighter.Technically you have more current available (non-PWM) because you're not wasting those extra milliamperes on the LED's in the opto's that you can't see anyway.:)

[smartalec]

so would i just have to replace the pic chips to use this deasign?
so i could run Y adapters on my cat 5's to each board, instead of series linking?

sounds like a great idea.

[dirknerkle]

so would i just have to replace the pic chips to use this deasign?
so i could run Y adapters on my cat 5's to each board, instead of series linking?

sounds like a great idea.

You don't have to replace the PICs -- just reflash them.

Yes, you could run Y-adapters off your RS485 and accomplish the same thing with a wired setup. However, remember that 485 has a limit of 32 "taps" off the main trunk line... so that would be 32 controllers.

(Hmmm...seems like 32 ought to be enough for most folks...:rolleyes:)

[dirknerkle]

One thing to note, is the default for this firmware is PWM where the default for the regular firmware is Non-PWM.


Yes, the downloadable ASM defaults to PWM. It was the default when we started experimenting so we left it that way. Users can certainly adjust the baud rate, PWM and the START_ADDR to their heart's content. :cool:

[budude]

Nice cooperative effort there folks - this is a perfect addition for the Wireless stuff for sure...

[smartalec]

You don't have to replace the PICs -- just reflash them.

Yes, you could run Y-adapters off your RS485 and accomplish the same thing with a wired setup. However, remember that 485 has a limit of 32 "taps" off the main trunk line... so that would be 32 controllers.

(Hmmm...seems like 32 ought to be enough for most folks...:rolleyes:)

Hmmm 32 x ren64 = 2048 channels, something tell's me if i went that many channels i would go crazy during sequencing.

i dont even know why i would be thinking replacing the pic's
it seems this new firmware will be the new renard protocall?

so this firmware is basicly like an update to the current renard firmware, but with alot of new functions with it?

[smartalec]

just been reading the wiki, an your firmware sounds like a god send.
eg, i can then design controllers just for certain lights. mega tree, arch's, icle's, floods.

sounds like a dream has been answered.

[ErnieHorning]

(Hmmm...seems like 32 ought to be enough for most folks...I'm pretty sure I read the same thing about 64 channels a few short years ago. I just seems a lot now. There may be something new that uses a lot of physical channels; video comes to mind. Though the spec is 32 loads, the chip I'm using claims 64 on the bus and new chips may be more.

This is a great idea and I may use it this year. One advantage of this in hardwire implementations is that a controller failure (or a GFCI trip) wouldn't kill all the upper channels anymore.

Note: Step 5 of 'How to Set the Start Address' in the Wiki mentions an error and references and example that is missing.

[Jrd]

Great work Dirknirkle!
So this new firmware reduces the cost to go wireless if you reflash your PICs with the addressable code and run the Xbees in receive only mode (except for the first one of course), saving the cost of one module.

[ErnieHorning]

I don't see how it would reduce the cost. You would need a receiver for every controller that didn't have an address of zero. I'm not sure it saves you anything other than you know exactly the address that a controller will respond to. The transmitter will still need to send all channels each time any channels changes, unless the plugin is changed.

[steve_hirst]

yes but what he is saying is that you don't need both the send ans recieve radios on the boards. all recieve except the first one from the vixen pc.

[dirknerkle]

I can't take credit for the mod--that was all Phil! But the feature gives much broader and easier control of all channels. Yes, you still need a receiving xbee at each controller but you no longer have to daisy chain them or screw around with direct radio addressing. It also eliminates the cumulative lag of retransmitting that is inevitable in the xbee daisy chain setup.


Great work Dirknirkle!
So this new firmware reduces the cost to go wireless if you reflash your PICs with the addressable code and run the Xbees in receive only mode (except for the first one of course), saving the cost of one module.

[smartalec]

I can't take credit for the mod--that was all Phil! But the feature gives much broader and easier control of all channels. Yes, you still need a receiving xbee at each controller but you no longer have to daisy chain them or screw around with direct radio addressing. It also eliminates the cumulative lag of retransmitting that is inevitable in the xbee daisy chain setup.

could you still daisy chain them this way? or would there be problems?

[ErnieHorning]

The protocol hasn't changed, it still operates like it always has. You can just have a controller that ignores all channels before it's own.

This give Renard the ability to function in both a serial and parallel mode.

[IdunBenhad]

Hi:
Thanks, ET AL, for another job well done. I am marking up at least 10 ATTABOYS to each of you on the big tally board.

I find the concept easy to understand. Dave's documentation and explanation make this so. I have used this type of addressing in my "working life" (long gone), so for me, it was duck-soup.

I am continually amazed at the talent this hobby has attracted, and all for "free"!

Thanks again, guys.

[mmulvenna]

Great job on the firmware and the very clear documentation.

Similar concept I have used for AL controllers.

I dont know anything about firmware but I have a question. Rather than set the controller address, after the math calculations, could the firmware have the starting channel set and then calculate and set the starting address?

Again, excuse the novice question.

[dirknerkle]

Since the pic firmware is static and there isn't a way to send anything from vixen other than the standard channel data, it must be preset. Good idea though!

Great job on the firmware and the verey clear documentation.

Similiar concept I have used for AL controllers.

I dont know anything about firmware but I have a question. Rather than set the controller address, after the math calculations, could the firmware have the starting channel set and then calculate and set the starting address?

Again, excuse the novice question.

[IdunBenhad]

Hi:
Mike: This had been discussed before in other threads, and I am not an expert in the PIC coding, but the way I understand it, there is too much overhead involved in the code to be able to have the controller calculate its' own address.

The problem is apparently in timing constraints and the PIC code being able to "keep up with decoding the channels " and keeping them in the right place. Also, there is a limit in the amount of memory available for the code.

Probably I should leave the explanation to the "big boys", because it is quite apparent they know a lot more about it than I do.

I'm just a "coaster" and depend on others to do my work for me. I just happily use their research and solutions and issue "ATTABOYS"

Oboy, Dave got ahead of me, as usual

[mmulvenna]

Since the pic firmware is static and there isn't a way to send anything from vixen other than the standard channel data, it must be preset. Good idea though!


So the firmware cant do any calculations? Something like

startchan = 25 ...set by the user rather than setting startaddr = 3
startaddr = 0
startaddr = startchan/ 8

You guys are way over me and this is a gross oversimplfication just trying to soak in as much as I can.

Am I understanding correctly that the firmware cannot "write" to the chip?
Again accept my novice questions and accept my huge attaboys.

[dirknerkle]

part of the problem is storing the value. The code has to be as tight as possible for memory/timing issues and with a calculation it would have to store 2 numbers instead of only one. It also protects againt invalid channels, say if a user put in 26 as the start channel. At runtime it would be problematic because it's not divisible by 8. This is more efficient in the long run.


So the firmware cant do any calculations? Something like

startchan = 25 ...set by the user rather than setting startaddr = 3
startaddr = 0
startaddr = startchan/ 8

You guys are way over me and this is a gross oversimplfication just trying to soak in as much as I can.

Am I understanding correctly that the firmware cannot "write" to the chip?
Again accept my novice questions and accept my huge attaboys.

[mmulvenna]

part of the problem is storing the value. The code has to as tight as possible for memory/timing issues and with a calculation it would have to store 2 numbers instead of only one. It also protects againt invalic channels, say if a user put in 26 as the start channel. At runtime it would be problematic because it's not divisible by 8. This is more efficient in the long run.

Cool, thanks for the clarification...and BTW

Happy Easter:smile::smile:

[Reddy_Kilowatt]

Yes, you could run Y-adapters off your RS485 and accomplish the same thing with a wired setup. However, remember that 485 has a limit of 32 "taps" off the main trunk line... so that would be 32 controllers.

(Hmmm...seems like 32 ought to be enough for most folks...:rolleyes:)

Ahh... Now I see another use for your Cat5 Expander Hub PCB (http://www.doityourselfchristmas.com/forums/dynamics/showentry.php?e=46&catid=8) in the copper section of the file library. :cool:

-Craig

[dirknerkle]

Ahh... Now I see another use for your Cat5 Expander Hub PCB (http://www.doityourselfchristmas.com/forums/dynamics/showentry.php?e=46&catid=8) in the copper section of the file library. :cool:

-Craig

Not a bad idea but that wasn't intended for serial, it was intended for SSR control and some pins are not connected. However, a similar board could be made to forward the proper lines for serial.

[dirknerkle]

could you still daisy chain them this way? or would there be problems?

You still have the option of creating a daisy chain, wirelessly or otherwise. By setting the START_ADDR to zero, the firmware is just straight Renard.

Wirelessly, you'd of course set an XBee to forward the signal to a specific radio by using that radio's address to daisy chain one controller to the next.

[Reddy_Kilowatt]

Not a bad idea but that wasn't intended for serial, it was intended for SSR control and some pins are not connected. However, a similar board could be made to forward the proper lines for serial.

After a little more investigation, it looks like something simular to a DMX splitter, could be a better route to go. Proper termination and drivers for each drop.

-Craig

[dirknerkle]

After a little more investigation, it looks like something simular to a DMX splitter, could be a better route to go. Proper termination and drivers for each drop.

-Craig

Craig, I added some lines and rearranged a few on the cat-5 expanded board to create a full, 8-line 5-port non-powered passive hub. I uploaded it to the file library's COPPER section if you care to etch one on your own. It would work as an RS-485 "splitter" to be sure!

-dave

[smartalec]

Craig, I added some lines and rearranged a few on the cat-5 expanded board to create a full, 8-line 5-port non-powered passive hub. I uploaded it to the file library's COPPER section if you care to etch one on your own. It would work as an RS-485 "splitter" to be sure!

-dave
could i use rj45 splitters like these
http://imgs.inkfrog.com/pix/bigkeyboard/RJ45-1to2.jpg

[daviddth]

Just be careful of splitters like that as they are often designed to give you 2 LAN points at the remote end of a cat 5 cable. 100MB networks often only use 4 of the 8 wires, leaving 4 "unused". Plug 2 lan ports into an adapter, run a single cable to a remote location & put the other end of the "splitter" there and you have 2 full-speed 100MB ports. Thats often better than "Sharing " a 100MB connection & putting a hub or switch at the other end if you are using the connection to send a lot of data.

I have a few like that and would be useless for what we want, but also a few which are effectively a "Double adapter" which would work perfectly

[j1sys]

Also, IMHO, RS485 is a bussed signal with terminated end. You might chane impedence too much with passive splitting.

[smartalec]

sounds like i have to look inside it, for 2.50 for 2 of them, there something i brought for the junk box
yep they are a true double adapter, (might have to use hot glue to seal it again tho.(them brittle clips broke when i got inside)
thanks for reminding me of that fact tho, i totaly forgot about it.


Just be careful of splitters like that as they are often designed to give you 2 LAN points at the remote end of a cat 5 cable. 100MB networks often only use 4 of the 8 wires, leaving 4 "unused". Plug 2 lan ports into an adapter, run a single cable to a remote location & put the other end of the "splitter" there and you have 2 full-speed 100MB ports. Thats often better than "Sharing " a 100MB connection & putting a hub or switch at the other end if you are using the connection to send a lot of data.

I have a few like that and would be useless for what we want, but also a few which are effectively a "Double adapter" which would work perfectly

[P. Short]

The wires from the splitter to the controller (Renard) boards should be kept as short as possible. I don't have a specific length limit to tell you, but I think that it should be on the order of inches, not feet. The reason for this is that long stub cables will cause signal reflections on the main cable, and hence noise. This requirement is similar to the DMX requirements.

In addition, you should disable the 120 Ohm terminator resistors on all of the Renard controllers connected in this way, except the end controllers.

[smartalec]

The wires from the splitter to the controller (Renard) boards should be kept as short as possible. I don't have a specific length limit to tell you, but I think that it should be on the order of inches, not feet. The reason for this is that long stub cables will cause signal reflections on the main cable, and hence noise. This requirement is similar to the DMX requirements.

In addition, you should disable the 120 Ohm terminator resistors on all of the Renard controllers connected in this way, except the end controllers.
so would it be best having the splitters next to the usb-rs485 or next to the controllers? im lost

[dirknerkle]

so would it be best having the splitters next to the usb-rs485 or next to the controllers? im lost

Yes. You don't want a lot of long cables going from the trunk line to a controller, keep them as short as is practical, hopefully very, very short!

[smartalec]

Yes. You don't want a lot of long cables going from the trunk line to a controller, keep them as short as is practical, hopefully very, very short!

so on my usb-rs485 could i run like a 4way double adapter then running them to the 4 main controllers, then series off them controllers.

i just found out the flaw of if one board fails they all go out,
one of the boards i built is experancing not working problems after 3weeks 24/7 run.
an i had it off for a week, started it going an no blinky flashie,jumped the rs485 line into another ren64 an away she went.

i cant wait to get a pic programmer an goto your firmware now.:)

[dirknerkle]

so on my usb-rs485 could i run like a 4way double adapter then running them to the 4 main controllers, then series off them controllers.


SA, we all are in the same boat sailing through untested waters here. Nobody has stepped forward with any first-hand, working information about the nuances of splitting an RS-485 line. And in absence of some really concrete "how-to" information about it, we are left to our wits and intuition....and what is written in "the books."

How short is a short cable? Is it 10 feet? 1 foot? 4 inches? I don't know. All I've read is "the shorter the better." Is it better to put the splitter near the PC or closer to the controller? I don't know -- all I know is shorter is better. Phil mentioned reflections which would cause noise in the line. We all would likely agree that noise is a bad thing when it gets to bad the accurate communication between devices ceases. So how much noise can your system tolerate before you get a lot of misfires? I dunno.

RS-232 specs say that you shouldn't go past 50 feet, but many have had no problems whatsoever at 100'. I've tried it myself at 100' and it worked just as well as with a 10-foot cable. RS-485 says 4000 feet is the max. I have no plans to test that, but if I found it worked at 6000 feet, would I be breaking the rules? Are the RS485 police going to come to my house and take me away???

You could be the first one to demonstrate that a 100' tap off the RS-485 line actually works -- or that it doesn't but a 25' tap does. You could be the first one to show that multiple lines directly from the RS-485 adapter works great -- or doesn't work at all. You could become famous for a treatise on "The DIYC Dos and Don'ts of RS-485 Connections!"

I have about a half-mile of last year's cat5 neatly spooled and hanging in my main controller cabinet, and I just may leave it that way and go completely wireless this year instead, for no other reason than just to see what happens. So I'll leave you to write the manual on RS-485 operations!

Go for it!

[P. Short]

The cables between the splitters can be long (otherwise there would not be any point to this), but the cables between the splitters and the controllers should be kept short (I would say 4"). If the USB-485 is connected in the middle of the cable run with a splitter (as opposed to being connected at the end), then the cable from the USB-485 adapter to the cable splitter should be kept similarly short.

Come to think of it, these types of considerations were one of the reasons why the Renard designs were set up to use point-to-point wiring instead of a bussed system. While DMX512 shows that these systems can be made to work reliably, it is sometimes hard to describe how to do that (especially without using powered repeaters).

[holtzj]

Just programmed my first pic such that it's not starting address 0, note that I have always used Renard-20071229.asm file to program. Learned a few things to pass along to other folks that my try this. First of all the define is START_ADDR as stated in most of the docs NOT START_ADDRESS which I found in some places. Second thing is that adding the START_ADDR define statement to the Renard-20071229.asm file doesn't work. I have to read the code after it didn't work, I would suggest using the Renard20090915.asm and not reprogramming the Renard20071229.asm file. The Renard20090915.asm file has the define START_ADDR statement(set to zero) but also has code in that file that uses the defined variable(I should have known this). Compiling the Renard20090915.asm produced 3 warnings for me that appear to be okay. I also found that programming the chips such that some are programmed with Renard-20071229.asm file and others are programmed with Renard-20090915.asm file appears to work fine.

I may not be the expert on this but, I wanted to pass long a few note to try and help others.

[dirknerkle]

Just programmed my first pic such that it's not starting address 0, note that I have always used Renard-20071229.asm file to program. Learned a few things to pass along to other folks that my try this. First of all the define is START_ADDR as stated in most of the docs NOT START_ADDRESS which I found in some places. Second thing is that adding the START_ADDR define statement to the Renard-20071229.asm file doesn't work. I have to read the code after it didn't work, I would suggest using the Renard20090915.asm and not reprogramming the Renard20071229.asm file. The Renard20090915.asm file has the define START_ADDR statement(set to zero) but also has code in that file that uses the defined variable(I should have known this). Compiling the Renard20090915.asm produced 3 warnings for me that appear to be okay. I also found that programming the chips such that some are programmed with Renard-20071229.asm file and others are programmed with Renard-20090915.asm file appears to work fine.

I may not be the expert on this but, I wanted to pass long a few note to try and help others.

The start address feature first became available for Renard with the 20090915 version of the firmware, so one should not expect any earlier versions to work properly simply by adding the start_address line.

The three errors you encounter upon compiling the firmware into HEX are expected and do not affect the operation of the software. This is outlined at step 5 of the How To Set the Start Address section of the configuration guide:

http://www.doityourselfchristmas.com/wiki/index.php?title=Renard_Start_Address_Configuration _Guide