--- In smartsockets@yahoogroups.com, "curwenx" <curwenx@...> wrote:
>
> The PIC chip is controlled using an UART right? I have plans to add a slave
mode to my clock kit as well (as an optional firmware), and that is what I
thought would be a cool use of smartsockets. My plan is to write it as an I2C
slave, but adding serial would be simple too.
>
Yes that sounds cool.
>
> If I do start a port I think it would be best to do it in generic C to be
easily portable to just about any platform: If I understand your code correctly,
it should be possible to make everything generic, and then have a runslice
function called from a uC timer that would take care of display animation.
Yes that's how it's done.
>
> Is there a specification for the smartsockets protocol available somewhere?
>
Not an official spec. The command list is in the files section for the relevant
smartsocket devices. I usually specify a 5mS period wait after sending a command
before sending another command, but for a lot of the commands this is very
pessimistic and most commands can be sent serially with a much smaller delay
than 5mS
There are no start characters or end characters, the data packet is trapped and
only valid data is interpretted. There is no checksum
function, but I have had no data corruption issues. A checksum function could
be added easily and users can be given the option to use it or not, I suppose.
Chris
Thanks Chris.
Are these two features implemented in the current firmware?
http://groups.yahoo.com/group/smartsockets/message/691
My PCB has pin 14 tied to GND, if the features are not implemented will this
need to be left floating instead of tied to GND?
Cheers
Simon
--- In smartsockets@yahoogroups.com, "fixitsan2" <fixitsan@...> wrote:
>
> That's correct, although I connected the blanking pin of the HV5812 to RB3 pin
in previous versions, it was never used. I had anticipated using blanking to
control display brightness by PWMing the blanking pin at one point.
> At the moment there is no blanking but i didn't like the strobing effects I
was getting PWMing the blanking pin as a result of beat frequencies related to
the muxing frequency
> i have always maintained the idea that I would like to add brightness control,
and if I do, it will probably be a software implemented routine because I will
be able to adjust the muxing time-space ratio to dim the display in a manner
which i hope won't cause any nasty flicker or other artifacts.
>
> Chris
>
--- In smartsockets@yahoogroups.com, "shklaw75" <shklaw75@...> wrote:
>
>
>
> Thanks Chris.
>
> Are these two features implemented in the current firmware?
>
> http://groups.yahoo.com/group/smartsockets/message/691
>
> My PCB has pin 14 tied to GND, if the features are not implemented will this
need to be left floating instead of tied to GND?
>
> Cheers
> Simon
Hi Simon, there was no need for these functions once I spun my own boards and
bought in ready made 35V PSU's, so they are defunct.
Pin 14 was a test mode feature, if you're tied it to ground I guess you don't
even use it ! Display testing is now done by sending either a single 'V'
(version display) or "ID" (enumerate and display)
The information about the current operational modes and the schematic is in the
manuals in the IV-17 files section.
Chris
Chris
--- In smartsockets@yahoogroups.com, "shklaw75" <shklaw75@...> wrote:
>
>
>
> Thanks Chris.
>
> Are these two features implemented in the current firmware?
>
> http://groups.yahoo.com/group/smartsockets/message/691
Having said no, I do have a version of code which does use these features if you
want to spin your own supply. The code is good version 13 code which I produced
for another group member recently.
Chris
Thanks Chris,
I will stick with the latest version of code without these features and power
the sockets with a separate supply.
Cheers.
Simon
--- In smartsockets@yahoogroups.com, "fixitsan2" <fixitsan@...> wrote:
>
> Having said no, I do have a version of code which does use these features if
you want to spin your own supply. The code is good version 13 code which I
produced for another group member recently.
>
> Chris
>
Unless we speak before tomorrow, I would just like to wish all group members a
Happy Christmas and thank you for your continued support and interest in these
projects.
It is 10 years ago that I began my first experiments with nixie tubes, when I
decided that I wanted to make a nixie clock for my father's 60th birthday
present. So, beginning in November I ordered tubes, some PICs, downloaded
Microchip's MPLAB for the first time and taught myself assembly language for
PICs. It was a steep learning curve considering the 10 week deadline, but I
couldn't afford a higher level language so battled on.
Then my interest continued with an invite from Ray Weisling to join the first
nixie group, NEONIXIE-L on Yahoo, when he saw me selling clock number 2 on eBay,
which I made in order to pay for both clocks.
It is nice to see so many of those members are also here, and with you there is
also a huge number of new people with an interest in nixies. It is nice to know
that so many people share an interest with yourself !
Although I built the first clock alone, it is true to say that I would not have
improved my skills or opened my mind to some very interesting ideas had it not
been for my membership of that group, and the support, the nagging, challenges
and humour shared among all members there and now here.
I seem to have taken those ideas sideways into developing the Smartsocket
concept, originally for neon based tubes and now for the IV-17 vfd tubes which I
first began experimenting with in 2007. (it has been a slow project !)
Without feedback from users I very much doubt that I would have been able to
focus on and direct the projects to their current iterations.
John Smout has left a great project in the files section for use by all members
using neon based display devices, which works very well.
I have also learnt about managing different (but very similar) versions of code.
Working closely with some of you to try to incorporate features and facilitate
your ideas has meant rapid development, sometimes with errors in coding which
did not become apparent until a later version highlighted the error.
However, things seem to have settled down more recently and I don't know of any
bugs with any code. There is a demand for a test function of the IV-17 devices.
Maybe the reason I didn't see the need at first has been because I don't have
any problems (not for any other reason than I already have devices which are
proven). I will try to produce more than just a segment test confidence
function.
What's next ?
The strong interest in an IV-17 vfd based device has got me looking at writing a
word generating device, along the lines of a FLW, but I like the idea of
incorporating a word ladder selection routine too. I have already tried writing
sample code for this and I like the challenge ! This would be a standalone
device, based on the Explorer kits, with a rotary encoder for use as the menu
system navigation and parameter setting input device. Anybody in possession of
an explorer kit already will be pleased to know it will be backwards compatible,
and will be available as a preprogrammed pic on it's own, if required.
Once again, thanks to all of you who have contributed already. Your input has
been very important to me as you can see.
Merry Christmas and the best of the season to you all and your families
Chris
Merry Christmas to you too and the rest of group.
You are doing a great job an it is very well done. You have spent many hours
of work wich you share with everybody!
Greetings, Sture
----- Original Message -----
From: "fixitsan2" <fixitsan@...>
To: <smartsockets@yahoogroups.com>
Sent: Saturday, December 24, 2011 1:57 PM
Subject: [smartsockets] Merry Christmas
> Unless we speak before tomorrow, I would just like to wish all group
> members a Happy Christmas and thank you for your continued support and
> interest in these projects.
>
> It is 10 years ago that I began my first experiments with nixie tubes,
> when I decided that I wanted to make a nixie clock for my father's 60th
> birthday present. So, beginning in November I ordered tubes, some PICs,
> downloaded Microchip's MPLAB for the first time and taught myself assembly
> language for PICs. It was a steep learning curve considering the 10 week
> deadline, but I couldn't afford a higher level language so battled on.
>
> Then my interest continued with an invite from Ray Weisling to join the
> first nixie group, NEONIXIE-L on Yahoo, when he saw me selling clock
> number 2 on eBay, which I made in order to pay for both clocks.
>
> It is nice to see so many of those members are also here, and with you
> there is also a huge number of new people with an interest in nixies. It
> is nice to know that so many people share an interest with yourself !
>
> Although I built the first clock alone, it is true to say that I would not
> have improved my skills or opened my mind to some very interesting ideas
> had it not been for my membership of that group, and the support, the
> nagging, challenges and humour shared among all members there and now
> here.
>
> I seem to have taken those ideas sideways into developing the Smartsocket
> concept, originally for neon based tubes and now for the IV-17 vfd tubes
> which I first began experimenting with in 2007. (it has been a slow
> project !)
>
> Without feedback from users I very much doubt that I would have been able
> to focus on and direct the projects to their current iterations.
>
>
> John Smout has left a great project in the files section for use by all
> members using neon based display devices, which works very well.
>
> I have also learnt about managing different (but very similar) versions of
> code. Working closely with some of you to try to incorporate features and
> facilitate your ideas has meant rapid development, sometimes with errors
> in coding which did not become apparent until a later version highlighted
> the error.
>
> However, things seem to have settled down more recently and I don't know
> of any bugs with any code. There is a demand for a test function of the
> IV-17 devices. Maybe the reason I didn't see the need at first has been
> because I don't have any problems (not for any other reason than I already
> have devices which are proven). I will try to produce more than just a
> segment test confidence function.
>
>
> What's next ?
> The strong interest in an IV-17 vfd based device has got me looking at
> writing a word generating device, along the lines of a FLW, but I like the
> idea of incorporating a word ladder selection routine too. I have already
> tried writing sample code for this and I like the challenge ! This would
> be a standalone device, based on the Explorer kits, with a rotary encoder
> for use as the menu system navigation and parameter setting input device.
> Anybody in possession of an explorer kit already will be pleased to know
> it will be backwards compatible, and will be available as a preprogrammed
> pic on it's own, if required.
>
>
> Once again, thanks to all of you who have contributed already. Your input
> has been very important to me as you can see.
>
> Merry Christmas and the best of the season to you all and your families
> Chris
>
>
>
>
>
>
>
> ------------------------------------
>
> Yahoo! Groups Links
>
>
>
Terrible sorry if this affects you, but it would seem that some pics with IV-17
Smartsocket code have been sent out with a baud rate of 38400.
If you have been having a problem getting your Smartsocket to work, please
consider testing with 38400 baud data.
The PIC datasheet has some confusion about the setting of the baudrate generator
BRGH bit on an earlier device which I used for prototyping, before I went to the
18f25k22 and the subsequent changes I made may have been carried over by the
inclusion of a library file containing the change.
At 38400 baud the 18f25k22 woorks flawlessly, unlike previous devices, which is
possibly due to the better quality internal oscillator used in this device, but
I haven't looked too closely at it to confirm that. I just know that I haven't
ever had to tweak the clock of an 18f25k22 like I have had to with, say, the
16F690 in order to get reliable serial data.
I am tempted to leave the speed at 38400, but it is no big deal to make it a pin
selectable function to include 38400 and 9600 baudrates.
Guus, if this is the source of the problem with your kit, I can only apologise
and will send it back with a photo of my Rudolph-red face.
Chris
Hello Chris,
Let's hope it is something as simple as that.
And if anything, it only shows that you're human as well. As such, you're
allowed to make mistakes.
BR/
Guus
>-- Oorspronkelijk bericht --
>To: smartsockets@yahoogroups.com
>From: "fixitsan2" <fixitsan@...>
>Date: Sat, 24 Dec 2011 13:35:47 -0000
>Subject: [smartsockets] Pride came before the fall
>Reply-To: smartsockets@yahoogroups.com
>
>
>Terrible sorry if this affects you, but it would seem that some pics with
>IV-17 Smartsocket code have been sent out with a baud rate of 38400.
>
>If you have been having a problem getting your Smartsocket to work, please
>consider testing with 38400 baud data.
>
>The PIC datasheet has some confusion about the setting of the baudrate
generator
>BRGH bit on an earlier device which I used for prototyping, before I went
>to the 18f25k22 and the subsequent changes I made may have been carried
over
>by the inclusion of a library file containing the change.
>
>At 38400 baud the 18f25k22 woorks flawlessly, unlike previous devices, which
>is possibly due to the better quality internal oscillator used in this device,
>but I haven't looked too closely at it to confirm that. I just know that
>I haven't ever had to tweak the clock of an 18f25k22 like I have had to
>with, say, the 16F690 in order to get reliable serial data.
>
>I am tempted to leave the speed at 38400, but it is no big deal to make
it
>a pin selectable function to include 38400 and 9600 baudrates.
>
>Guus, if this is the source of the problem with your kit, I can only apologise
>and will send it back with a photo of my Rudolph-red face.
>
>Chris
>
--- In smartsockets@yahoogroups.com, "guus.assmann@..." <guus.assmann@...>
wrote:
>
> Hello Chris,
>
> Let's hope it is something as simple as that.
> And if anything, it only shows that you're human as well. As such, you're
> allowed to make mistakes.
>
> BR/
> Guus
Would anybody have a problem if 38400 becomes the default speed and 9600 became
the option ? I certainly am happy with the performance of the 18f25k22 at the
higher speed.
I think the Arduino can run at 38400, for the builders preferring to make
Arduino controllers.
My mind has just started to mull over how best I could implement 'approximate
clock' time displays as an selectable option - and I was hoping for a quiet
Christmas eve playing bboard games with my family.
Things will look better once I have a drink !
Cheers everybody
Chris
I'm still constructing the "top deck", haven't got as far as that yet! Those
IV-14 wires are pesky ;-)
Slight error on that PCB BTW, C6 is labelled C5 (which is also present on the
controller board), and possibly its pads are slightly on the wider side of
spacing.
I'd probably prefer a lower baud rate to make interfacing with lower-spec PICs
easier (I'm considering adding a FLW generator). I do have a PICkit2 programmer.
--
Cheers
Derryck
On 24 Dec 2011, at 13:35, fixitsan2 wrote:
> Terrible sorry if this affects you, but it would seem that some pics with
IV-17 Smartsocket code have been sent out with a baud rate of 38400.
>
> If you have been having a problem getting your Smartsocket to work, please
consider testing with 38400 baud data.
>
--- In smartsockets@yahoogroups.com, Derryck Croker <derryck@...> wrote:
>
> I'm still constructing the "top deck", haven't got as far as that yet! Those
IV-14 wires are pesky ;-)
Have you tried an IV-17 or IV-4 instead Derryck, might be easier ;)
>
> Slight error on that PCB BTW, C6 is labelled C5 (which is also present on the
controller board), and possibly its pads are slightly on the wider side of
spacing.
Heck. Thanks for pointing out the naming error. The pad size issue will need to
be tweaked in another version, but probably supplying larger sized capacitors
will make it easier to live with until then.
>
> I'd probably prefer a lower baud rate to make interfacing with lower-spec PICs
easier (I'm considering adding a FLW generator). I do have a PICkit2 programmer.
>
I know I mentioned it here first, but now that I look harder most pics can do
the speed easily enough, even a bottom line capable 16f631/16f690 can do upto
115.2k at 3.6864MHz, but it is trivial to make it pin selectable in future
versions
If anyone has been negatively affected by a change of speed up to the faster
38400 baud and needs a lower speed pic in the meantime please don't hesitate to
contact me immediately for a quick solution.My error is my responsibility :)
Chris
--- In smartsockets@yahoogroups.com, Derryck Croker <derryck@...> wrote:
> I'm still constructing the "top deck", haven't got as far as that yet! Those
IV-14 wires are pesky ;-)
Here's the method I use - starting on the left side of the tube (where the index
pin 22 is), I isolate the 7 leads that will go on the left strip of pads and
curl the other leads back slightly. I then hold the tube at an angle (tilted
toward the front) and tilt it back, inserting each of the 7 leads in sequence
from front to back. Once all 7 are in, I bend over the front and back leads
around 1/4" from the end (to keep the tube from popping out). Next I do the
front and rear strips of 3 from left to right. These can be slightly curved to
get them into the holes. Again, I bend over the last 2 pins on each row to keep
the tube from popping out. Lastly, I do the 8 pins on the right side, which will
need a more pronounced bend to get them into the holes.
Once all of the pins are in, I rock the tube from front to back to push it
further into the board. Using needlenose pliers, I gently tug on any leads that
try to bunch up between the tube and the board. Once I have the tube down
approximately as low as I want it, I bend over the 4 corner leads to hold it in
position.
I repeat the procedure for the other 3 tubes. After all 4 tubes are on the
board, I align the first tube as I want it and use solder to tack only the 4
corner leads to the board. I then do the same with the other 3 tubes, making
sure that the tubes are in the same relative position between the front of the
board and the rear, that the bottom of each tube's segments are level with each
other, the tubes are facing forward exactly and not tilted toward / away from
each other. Lastly, I look down the row of tubes to make sure they're all
aligned. Minor adjustments can be made at this point without needing to desolder
the 4 pins per tube already soldered. A major misalignment may require one or
more pins to be desoldered (or at least melted enough to move the tube).
I decided to position my tubes further away from the board than in the
illustrations in the assembly manual. This may reduce stress on the leads where
they pass through the glass on the base of the tube. Of course, if you are
planning on fitting the completed board into an existing case, verify that it
will still fit (and look OK) with the tubes mounted further away from the board.
Here's a photo showing the lead detail from one of the boards I assembled:
http://www.tmk.com/transient/6F5S8472-s.jpg
> Slight error on that PCB BTW, C6 is labelled C5 (which is also present on the
controller board), and possibly its pads are slightly on the wider side of
spacing.
I actually found that capacitor easier to solder than the resistors on both
boards due to the "overhang" of the pads:
http://www.tmk.com/transient/6F5S8466-s.jpg
Hi Chris,
How about keeping the default at 9600 and having the option to change to 38400
if people desire? That keeps the compatibility with slower devices, as Derryck
mentioned, and more stability at the slower speed?
You mentioned that there was some issues at the higher speed:
http://groups.yahoo.com/group/smartsockets/message/800
would it be easier to keep it at the slower speed? (if it ain't broke!)
Cheers.
Simon
--- In smartsockets@yahoogroups.com, "fixitsan2" <fixitsan@...> wrote:
> Would anybody have a problem if 38400 becomes the default speed and 9600
became the option ? I certainly am happy with the performance of the 18f25k22 at
the higher speed.
>
> I think the Arduino can run at 38400, for the builders preferring to make
Arduino controllers.
>
> My mind has just started to mull over how best I could implement 'approximate
clock' time displays as an selectable option - and I was hoping for a quiet
Christmas eve playing bboard games with my family.
>
> Things will look better once I have a drink !
> Cheers everybody
>
> Chris
>
--- In smartsockets@yahoogroups.com, "shklaw75" <shklaw75@...> wrote:
>
> Hi Chris,
>
> How about keeping the default at 9600 and having the option to change to 38400
if people desire? That keeps the compatibility with slower devices, as Derryck
mentioned, and more stability at the slower speed?
>
> You mentioned that there was some issues at the higher speed:
http://groups.yahoo.com/group/smartsockets/message/800
> would it be easier to keep it at the slower speed? (if it ain't broke!)
>
> Cheers.
> Simon
>
>
Thanks for the comment Simon.
The reason I ask about it is because, as I pointed out already, the reliability
of 38400 on the 18f25k22 is faultless. I've put it down to the excellent
oscillator which is used in this device, much better than the older internal RC
device.
The Smartsocket doesn't communicate with anything but Smartsockets and hosts, so
it is only the host which needs to be considered for compatibility. Any host
which has enough memory to to make effctive use of the Smartsockets message
display capabilities is probably already compatible.
I was the one who suggested keeping the speed low first, but now that I've
thought about it more I can't see any reason not to use higher speeds if they
are available, which goes towards reducing latency on arrays using several SS's
daisychained togather.
I would be interested in hearing from someone who can't run at 38400 to say what
the reason is ?
Chris
On 26 Dec 2011, at 04:12, Terry wrote:
>
>
> --- In smartsockets@yahoogroups.com, Derryck Croker <derryck@...> wrote:
>> I'm still constructing the "top deck", haven't got as far as that yet! Those
IV-14 wires are pesky ;-)
>
> Here's the method I use - starting on the left side of the tube (where the
index pin 22 is), I isolate the 7 leads
Thanks - my method was to start at the index and work clockwise and
anti-clockwise bending over each wire as it went in to keep in place. Flat nose
pliers and wide bladed tweezers to straighten the wires and pull through. Have
to be careful that a rotational set doesn't take place.
Construction has had to take a back seat this week.
--
Cheers
Derryck
On 25 Dec 2011, at 10:36, fixitsan2 wrote:
>
>
> --- In smartsockets@yahoogroups.com, Derryck Croker <derryck@...> wrote:
>>
>> I'm still constructing the "top deck", haven't got as far as that yet! Those
IV-14 wires are pesky ;-)
>
> Have you tried an IV-17 or IV-4 instead Derryck, might be easier ;)
Inflation ;-)
>>
>> Slight error on that PCB BTW, C6 is labelled C5 (which is also present on the
controller board), and possibly its pads are slightly on the wider side of
spacing.
>
> Heck. Thanks for pointing out the naming error. The pad size issue will need
to be tweaked in another version, but probably supplying larger sized capacitors
will make it easier to live with until then.
No problem - anyone with the skills to solder this kit will soon sort it out.
Hmm, I'd probably label the bags with the component numbers now I think of it.
>> I'd probably prefer a lower baud rate to make interfacing with lower-spec
PICs easier (I'm considering adding a FLW generator). I do have a PICkit2
programmer.
>>
>
> I know I mentioned it here first, but now that I look harder most pics can do
the speed easily enough, even a bottom line capable 16f631/16f690 can do upto
115.2k at 3.6864MHz, but it is trivial to make it pin selectable in future
versions
I guess I need to up my game from the 16F628 and internal osc (I was going to
use an eeprom to hold the data for the FLW) ;-)
Cheers
Derryck
--- In smartsockets@yahoogroups.com, Derryck Croker <derryck@...> wrote:
>
>
> I guess I need to up my game from the 16F628 and internal osc (I was going to
use an eeprom to hold the data for the FLW) ;-)
>
> Cheers
>
> Derryck
>
I don't see why you can't use the 16F628 Derryck, it can do serial data upto
250k baud off the internal 4MHz oscillator, it's all in the datasheet.
However (!) one gotcha is that as I've already mentioned, the internal
oscillators of early pics are more susceptible to temperature drift than the
newer ones. If the baudrate is accurate at 25 Celsius at 5V don't expect it to
keep working at 10 Celsius too.(or at 4.8V either) It might work, it might not.
Results vary batch to batch
I can't see you having a problem though, with running the 16F628 from a 4MHz
crystal.
Chris
--- In smartsockets@yahoogroups.com, "fixitsan2" <fixitsan@...> wrote:
>
>
> I don't see why you can't use the 16F628 Derryck, it can do serial data upto
250k baud off the internal 4MHz oscillator, it's all in the datasheet.
Actually Derryck, according to Farnell, the 16F1518 (latest series) is cheaper
than the 16F628. It has more than enough onboard memory to store over 4000 four
letter words as well as your program, and will cope with 38400baud without a
crystal.
It would save you money because it is cheaper because you don't need another
IC(eeprom), or a seperate socket, or a crystal. Unless you have 16F628's with
nothing to do it saves you a lot of trouble and gains you a lot of simplicity
and stability/reliability.
Chris
For flying lead tubes simply cut each lead about 1/8 inch shorter as you go around the tube, this makes the ends of the leads like a little staircase, then insert the longest one, the next longest etc. Be sure to plan well so you leave enough length to have the tube sit at the desired height once all leads are in place.
Sent from my iPad
On Dec 27, 2011, at 9:04, Derryck Croker <derryck@...> wrote:
On 25 Dec 2011, at 10:36, fixitsan2 wrote:
>
>
> --- In smartsockets@yahoogroups.com, Derryck Croker <derryck@...> wrote:
>>
>> I'm still constructing the "top deck", haven't got as far as that yet! Those IV-14 wires are pesky ;-)
>
> Have you tried an IV-17 or IV-4 instead Derryck, might be easier ;)
Inflation ;-)
>>
>> Slight error on that PCB BTW, C6 is labelled C5 (which is also present on the controller board), and possibly its pads are slightly on the wider side of spacing.
>
> Heck. Thanks for pointing out the naming error. The pad size issue will need to be tweaked in another version, but probably supplying larger sized capacitors will make it easier to live with until then.
No problem - anyone with the skills to solder this kit will soon sort it out. Hmm, I'd probably label the bags with the component numbers now I think of it.
>> I'd probably prefer a lower baud rate to make interfacing with lower-spec PICs easier (I'm considering adding a FLW generator). I do have a PICkit2 programmer.
>>
>
> I know I mentioned it here first, but now that I look harder most pics can do the speed easily enough, even a bottom line capable 16f631/16f690 can do upto 115.2k at 3.6864MHz, but it is trivial to make it pin selectable in future versions
I guess I need to up my game from the 16F628 and internal osc (I was going to use an eeprom to hold the data for the FLW) ;-)
Thanks Chris, sounds like there are more advantages than disadvantages with the
faster speed.
Simon
--- In smartsockets@yahoogroups.com, "fixitsan2" <fixitsan@...> wrote:
>
> Thanks for the comment Simon.
> The reason I ask about it is because, as I pointed out already, the
reliability of 38400 on the 18f25k22 is faultless. I've put it down to the
excellent oscillator which is used in this device, much better than the older
internal RC device.
>
> The Smartsocket doesn't communicate with anything but Smartsockets and hosts,
so it is only the host which needs to be considered for compatibility. Any host
which has enough memory to to make effctive use of the Smartsockets message
display capabilities is probably already compatible.
>
> I was the one who suggested keeping the speed low first, but now that I've
thought about it more I can't see any reason not to use higher speeds if they
are available, which goes towards reducing latency on arrays using several SS's
daisychained togather.
>
> I would be interested in hearing from someone who can't run at 38400 to say
what the reason is ?
>
> Chris
>
I've had a few requests for pictures of my completed Smartsockets, so I figured
I'd oblige and link one here for all to see:
http://www.tmk.com/transient/6F5S8480-s.jpg
The short cables on the left side of the back 3 boards are to connect all of the
boards together in a string. I'm using plugs and pins while testing. Once I have
everything set the way I want it, I'll mount all four boards on a plastic base
and use telco (#24) wire-wrap wire on the pins to connect all of the boards
together.
On 27 Dec 2011, at 18:51, Neil Breeden wrote:
>
>
> For flying lead tubes simply cut each lead about 1/8 inch shorter as you go
around the tube, this makes the ends of the leads like a little staircase, then
insert the longest one, the next longest etc. Be sure to plan well so you leave
enough length to have the tube sit at the desired height once all leads are in
place.
Started off doing that, but chickened out with thoughts of your last sentence
came into view ;-)
Cheers
Derryck
On 27 Dec 2011, at 18:40, fixitsan2 wrote:
> 16F1518
Plenty of poke there ;-)
Thanks for the pointer!
One silly question, when I fire up for the first time, and without connecting up
to some kind of terminal to send commands from, will I expect to see some kind
of greeting message?
Cheers
Derryck
--- In smartsockets@yahoogroups.com, Derryck Croker <derryck@...> wrote:
>
>
> One silly question, when I fire up for the first time, and without connecting
up to some kind of terminal to send commands from, will I expect to see some
kind of greeting message?
>
> Cheers
>
> Derryck
>
no Derryck, the display is purposely blank. I figured that some people would
want to power the display's down when there is no data to display, say if you're
making an RSS feed reader or an SMS display terminal. Every time you receive a
text message under those conditions the tubes will cycle through a welcome
message first, probably being quite annoying.
I have just added a test message routine. Pulling pin 1 low forces the code into
routines which produces test patterns suitable for indicating shorts between
segments as well as shorts between screens, which could possibly occur if there
is a solder bridge on any tube driver pins. The test also confirms that the pic
controls the tube driver correctly. I am going to add a pin which mirrors the
state of pin 1, which will confirm that the code is actually when it's state
flips in accordance with pin1's state.
For the baudrate issues, I'm looking to implement auto baudrate detect which
just seems like it will take all worries away in one fell swoop.
Anybody looking to upgrade can do so, if you have the blank pics I sent out with
your kit I can program them for you.
I think the autobaud version will not be downwards compatible with previous
versions, but I have to prove that yet. I will save the code with latest
features seperately before adding autobaud.
I have added a couple of GeekKlok fonts (all credit to the authour Ray Weisling)
they are included only for demonstration purposes.
More news soon !
Chris
The test mode for confirming segment independence and screen independence (no
shorts,especially at the HV driver) has been added.
In response to the crushing pressure and demand (!) for 9600 baud I have made
9600 the standard for now.
I have started to tweak about with the autobaud facility of the EUSART, which
seems to work exceptionally well, however, my message parsing interrupt routine
now needs to be adjusted for each individual baudrate. Yuck.
FYI, anybody dabbling in PICs, if a device has the EUSART (not the plain USART)
you set the ABDON bit to a 1, and then after you expect the character "U" to
have been received from the host take a look at the RCIF bit. If RCIF was set
then the new baudrate has been acquired, SPBRG (or SPBRGH:SPBRGL if you use 16
bit mode) has been set correctly to match the pic's EUSART speed to the host's
speed. How easy is that !
So for now, the default is 9600 and the automatic baudrate will be added later,
once I have completed some other things which are higher up on the list of
priorities.
V2.27
Chris
On 29 Dec 2011, at 00:11, fixitsan2 wrote:
> The test mode for confirming segment independence and screen independence (no
shorts,especially at the HV driver) has been added.
Thanks Chris.
I thought it was a good idea anyway, instant gratification :-)
Happy to program the blank PIC myself as soon as the hex file is ready
somewhere.
Cheers
Derryck
Features added or improved.
(skip the details if you wish but *please* read the final paragraph)
-Working autobaud detection
At speeds between 9.6k and 60k the Smartsockets synch up well as long as
character "U" is sent between 400mS - 1500mS after power up. If no character "U"
is received during that time the data speed then defaults to 9600
-50 character limit
Increased from the previous limit. Messages of upto 50 characters can be sent to
the sockets, very useful if you have to scroll a long message
-Less aggressive end of message detection
A need to relax the message data validation test period has arisen (used when
receiving data to detect the end of a message), and has been included. The
minimum inter message period of 5mS should be observed.
-Blank tubes don't have sparkling hotspots
As is common with some VFD devices, it is difficult to make them completely
blank when they are included in a multiplexed array. Usually the screen is
switched on regardless of whether any segments are required to be illuminated.
In the IV-17 this produces hotspots which glow faintly. It would probably only
be an issue in a darkened room. By switching off the screen for any tubes which
does not have any data to be displayed the tubes can now be turned completely
off
-Memory allocation error rectified
The compiler which I am using has produced a version of code where the storage
location of an array has been set to an inappropriate memory address. This has
been reported to the manufacturer.
The memory allocation error may or may not be something which has affected a
version of code which I have already sent out on programmed PICs, it is
impossible for me to say.
Therefore I am prepared to send to anyone who has already received a programmed
pic a replacement device. If you are having trouble communicating with a
Smartsocket or if it appears to behave erratically please don't wait, please get
in touch. This offer applies to anyone who has the first iteration of the
project which included surface mount pics. If you could send me the controller
board I will be happy to reprogram it and help with the cost of shipping too.
I want to make sure that any erroneous version of previous code is removed from
circulation
Chris
--- In smartsockets@yahoogroups.com, "fixitsan2" <fixitsan@...> wrote:
>This offer applies to anyone who has the first iteration of the project which
included surface mount pics.
I meant to say, this offer applies to everyone including anyone who has an
earlier version on a surface mount pic. /:)
Send Email
