Loading ...
Sorry, an error occurred while loading the content.

Re: [smartsockets]Where and what? B7971

Expand Messages
  • fixitsan2
    ... Thanks Guus. The more I think about this the more I think it is likely that the sockets will always be connected up to a controller with some sort of
    Message 1 of 22 , Jan 27, 2010
    • 0 Attachment
      --- In smartsockets@yahoogroups.com, guus.assmann@... wrote:
      >
      > Hello Chris,
      >
      > Why not do both, a part for all tubes and a part for indivudual tubes.
      > It should be "just" another devision of the memory and the distinction in
      > the command to address the common or individual one.


      Thanks Guus. The more I think about this the more I think it is likely that the sockets will always be connected up to a controller with some sort of intelligent control features which could easily reprogram a charset whenever required.

      Keeping some sort of compatibility among the different types of sockets means that a single unified controller can be used. John's clock for B7971 tubes for example should be allowed to work equally well with a new socket version which comes along, to cut down on the number of controller versions required, but I accept there might come a point when the hardware dictates that different versions will be required.


      Chris
    • John
      Chris, Changing the GUI to match whatever you come up with will be trivial. http://www.tayloredge.com/utilities/vbapps/Installers/iCalculators.exe
      Message 2 of 22 , Jan 28, 2010
      • 0 Attachment
        Chris,

        Changing the GUI to match whatever you come up with will be trivial.

        http://www.tayloredge.com/utilities/vbapps/Installers/iCalculators.exe
        <controllers><[1386] SmartSocket>
        http://www.tayloredge.com/reference/Circuits/1386SmartSocket/editor.GIF
        (To edit the font, click on the segments in the picture or edit the pattern of 1/0s; these two entry methods track each other.)

        The next enhancement of the tool will be to use the character editor to create, save, load and upload entire UCD character sets to sockets. Doing this from a PC is fast and easy and since the UDC is non-volatile you could presumably abstract the UCD functionality out of the master embedded controller: "A" would remain the same in the master. Program every socket string in the string or each individually so they would display their interpretation of the same character.

        When you build the 16 segment displays, this will be even more useful as the alphabet can now be enhanced: The 14 segment display was the bare minimum for A-Z and 0-9.

        jt

        --- In smartsockets@yahoogroups.com, "fixitsan2" <fixitsan@...> wrote:
        >
        >
        >
        > --- In smartsockets@yahoogroups.com, guus.assmann@ wrote:
        > >
        > > Hello Chris,
        > >
        > > Why not do both, a part for all tubes and a part for indivudual tubes.
        > > It should be "just" another devision of the memory and the distinction in
        > > the command to address the common or individual one.
        >
        >
        > Thanks Guus. The more I think about this the more I think it is likely that the sockets will always be connected up to a controller with some sort of intelligent control features which could easily reprogram a charset whenever required.
        >
        > Keeping some sort of compatibility among the different types of sockets means that a single unified controller can be used. John's clock for B7971 tubes for example should be allowed to work equally well with a new socket version which comes along, to cut down on the number of controller versions required, but I accept there might come a point when the hardware dictates that different versions will be required.
        >
        >
        > Chris
        >
      • John
        The full font management system is in place along with a simple animation utility. jt http://www.tayloredge.com/reference/Circuits/1386SmartSocket/editor.GIF
        Message 3 of 22 , Jan 30, 2010
        • 0 Attachment
          The full font management system is in place along with a simple animation utility.

          jt

          http://www.tayloredge.com/reference/Circuits/1386SmartSocket/editor.GIF

          http://www.tayloredge.com/utilities/vbapps/Installers/iCalculators.exe
          <controllers><[1386] SmartSocket>
        • John
          GUI is updated... Don t let my wife catch me playing with SmartSockets!!! http://www.tayloredge.com/reference/Circuits/1386SmartSocket/index.html jt
          Message 4 of 22 , Jan 31, 2010
          • 0 Attachment
            GUI is updated... Don't let my wife catch me playing with SmartSockets!!!

            http://www.tayloredge.com/reference/Circuits/1386SmartSocket/index.html

            jt

            --- In smartsockets@yahoogroups.com, "John" <jpt@...> wrote:
            >
            > The full font management system is in place along with a simple animation utility.
            >
            > jt
            >
            > http://www.tayloredge.com/reference/Circuits/1386SmartSocket/editor.GIF
            >
            > http://www.tayloredge.com/utilities/vbapps/Installers/iCalculators.exe
            > <controllers><[1386] SmartSocket>
            >
          • fixitsan2
            ... John, the new command is in binary format, not ascii. The reason for the change was because it was the best way to maximise the eeprom space (1008/4 bytes
            Message 5 of 22 , Feb 1, 2010
            • 0 Attachment
              --- In smartsockets@yahoogroups.com, "John" <jpt@...> wrote:
              >
              > Chris,
              >
              > Changing the GUI to match whatever you come up with will be trivial.
              >

              John, the new command is in binary format, not ascii. The reason for the change was because it was the best way to maximise the eeprom space (1008/4 bytes per digit)

              The new command to write a UDC is as follows

              $B7W<d><c><16-bit segment pattern>

              "$B7W" is the ascii header, same as before

              "d" is the binary digit position, range = 1-254
              "c" is the UDC character position to write, binary 0 - 125
              "16-bit pattern" is the segment pattern. Same as the original version except the "0" and "1" characters are no longer ascii character 0 and 1, but are binary numbers 0 and 1

              NB there is no CR/LF following this command because each byte is counted on arrival.

              I hope to change the other smartsocket types to use this format in the future, but in the meantime using the 'wrong' UDC write instruction type for a particular socket should result in that instruction being ignored.

              It would be really easy to write a master device which outputs either or both formats.

              Chris
            • fixitsan2
              I wish we could edit posts... I forgot to mention that the new write command requires a minimum of 10mS to take effect, and therefore all write commands ought
              Message 6 of 22 , Feb 1, 2010
              • 0 Attachment
                I wish we could edit posts...

                I forgot to mention that the new write command requires a minimum of 10mS to take effect, and therefore all write commands ought to be followed with a 10mS pause.

                An example, using PIC Basic is as follows....

                Hserout ["$B7W",2,2,0,0,0,1,1,1,0,0,0,1,1,1,0,0,0,1]
                pause 10

                This command will write the bit pattern 0001110001110001 to segments abcdefghijklmnop , and save it as UDC #2 in digit #2.



                Chris
              • fixitsan2
                I would like to know if anybody thinks it would be of use to have a command which allows the user direct access to the segments of a particular tube. The
                Message 7 of 22 , Feb 1, 2010
                • 0 Attachment
                  I would like to know if anybody thinks it would be of use to have a command which allows the user direct access to the segments of a particular tube.

                  The command could follow a similar format to the UDC write command, except no eeprom space would be used at that time, the bitpattern transmitted in the instruction will be displayed immediately on the relevant segments.

                  The only downside that I can see is that there would be a delay in displaying each digit in this way, of about 20mS per digit. On the upside, any pattern at all could be displayed and the combinations of patterns are not limited to the number of free UDC's. If the Host controller has 3kB of ram then it could all be used to display bespoke characters and would not require the intermediate step of packing the UDC's

                  Chris
                • John
                  ... With a binary fixed length command format, how do you ensure that only good packets are being acted on? With the display of the date, time and such,
                  Message 8 of 22 , Feb 2, 2010
                  • 0 Attachment
                    > > Chris,
                    > >
                    > > Changing the GUI to match whatever you come up with will be trivial.
                    > >
                    >
                    > John, the new command is in binary format, not ascii. The reason for the change was because it was the best way to maximise the eeprom space (1008/4 bytes per digit)

                    With a binary fixed length command format, how do you ensure that only good packets are being acted on? With the display of the date, time and such, serial data errors are washed out because the data is continuously updated but UDC data once stored in EEPROM becomes the permanent representation of that data, errors or not. Using a bit-mapped command that writes the specific pattern to each display instead of an index pointing to a stored pattern would maintain the natural error tolerance of data redundancy and would only require as much memory in the master as the number of unique characters (This is what I do when I switch the SmartNixie modules to display in 7-segment Numitron format instead of 1-of-10 nixie format).

                    I suppose that the master could monitor the output from the last slave to compare it to the original data for error detection since the RS232 is simplex: There is no way for a master to know whether a slave is happy with its data.

                    jt
                  • fixitsan2
                    ... There is no way for a master to know whether a slave is happy with its data. ... No there isn t, but the user will be able to tell if they are happy with
                    Message 9 of 22 , Feb 3, 2010
                    • 0 Attachment
                      --- In smartsockets@yahoogroups.com, "John" <jpt@...> wrote:
                      There is no way for a master to know whether a slave is happy with its data.
                      >
                      > jt
                      >


                      No there isn't, but the user will be able to tell if they are happy with the results or not.I'm not trying to be ignorant but this isn't a safety critical application.

                      The eeprom write command is unlike the other display commands because it is likely that the programmer will write them one at a time and test them immediately afterwards, noticing any details at that time.

                      Also, any data errors will show up as general bad performance and the unit not working very well, if at all.

                      The eeprom write command still uses the '$B7' header , which is still checked as it arrives, and if those characters are received intact the write command is allowed to proceed. If there are data errors then all the other commands like $B7E, $B7M, etc will be affected too and the user will deal with those problems in their usual manner.

                      I could add a simple XOR-ing checksum with very little trouble, if it is generally felt that data reliability is an area of concern, but my own experience leads me to believe that if you can send ordinary $B7M commands and the display works properly then there is nothing wrong with the data transmission.
                    Your message has been successfully submitted and would be delivered to recipients shortly.