On Saturday, December 11, 2021 at 2:02:28 AM UTC-5, David Lesher wrote:
> Don Y <blocked...@foo.invalid> writes:
>
>
> >That's interesting. Usually, there are noise and ground issues
> >on lengthy runs, esp if DC-coupled.
>
> >> d) The system is based around a custom NXP-based controller. It
> >> talks to the EDS's via TCP/IP. It talks to other industrial gear
> >> via RS-485.
> ...
> >If you think it will work for you -- and is already in line
> >with other "solutions" you've deployed -- then go for it!
> So we are NOW looking at using the DS28E18 or DS28E17 1-Wire to
> I2C chips as it seems there are a metric ****load of displays
> driven by same:
>
> <https://www.aliexpress.com/w/wholesale-2.42-i2c-oled.html>
>
> Both are 3.3v which require a bidir level shifter but that's perhaps
> doable.
"Quickswitch" is a brand name I believe, but there are multiple sources. Or you can roll your own with a FET on each of the clock and data lines. Tie the gate of a MOSFET to the 5 volt rail through a diode and you should get the right switching voltage to disable the channel for any input greater than about 3 volts. Or use one of the switch based logic interface parts. It essentially creates a bi-dir drive that is totem pole up to about 3 volts and is open drain above that. So you get the rapid rise in voltage through the full 3 volt range with no issues of over voltage on the 3.3 volt side.
I strongly recommend you avoid Aliexpress though. Find other sources. Aliexpress is not there for the buyers.
--
Rick C.
-- Get 1,000 miles of free Supercharging
-- Tesla referral code - https://ts.la/richard11209
Reply by David Lesher●December 11, 20212021-12-11
Don Y <blockedofcourse@foo.invalid> writes:
>That's interesting. Usually, there are noise and ground issues
>on lengthy runs, esp if DC-coupled.
>> d) The system is based around a custom NXP-based controller. It
>> talks to the EDS's via TCP/IP. It talks to other industrial gear
>> via RS-485.
...
>If you think it will work for you -- and is already in line
>with other "solutions" you've deployed -- then go for it!
So we are NOW looking at using the DS28E18 or DS28E17 1-Wire to
I2C chips as it seems there are a metric ****load of displays
driven by same:
<https://www.aliexpress.com/w/wholesale-2.42-i2c-oled.html>
Both are 3.3v which require a bidir level shifter but that's perhaps
doable.
--
A host is a host from coast to coast...............wb8foz@panix.com
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
Reply by Don Y●December 4, 20212021-12-04
On 12/3/2021 11:39 PM, David Lesher wrote:
> Thank you for all your responses.
>
> a) This is not a high-production product; rather it's a 1 or 2
> off custom device for use with an existing system.
>
> b) That includes a working 1_Wire(tm) system. It uses multiple
> Embedded Data System OW-Servers that have 3 channels of 1_Wire
> devices, and supports multiple high-level TCP/IP protocols;
> no bit banging needed.
>
> c) It works well with multiple devices on long (multiple 100's
> of ft) twisted pair cable runs. We've not seen any error issues
> so far.
That's interesting. Usually, there are noise and ground issues
on lengthy runs, esp if DC-coupled.
> d) The system is based around a custom NXP-based controller. It
> talks to the EDS's via TCP/IP. It talks to other industrial gear
> via RS-485.
>
> We pondered driving the display via RS-485, but doubt that
> offers major advantages. There's no available RS-232 on the NXP,
> even if it would run over the cable run available.
>
> Does the above inspire solutions not yet offered?
If you think it will work for you -- and is already in line
with other "solutions" you've deployed -- then go for it!
I've taken to using ethernet over CAT5 for most of my
interconnects, now. But, that's primarily because it
affords me gobs of bandwidth (which also includes being
able to push new firmware on-the-fly)
I had cobbled together a "data-over-power" solution to
communicate with a repurposed Nest thermostat using the
two unused conductors in the thermostat wiring harness
but found it quickly ran out of bandwidth. Even encoding
terse "commands" that could be executed by the MCU
*behind* the Nest (e.g., 0x07 = flash display, 0x08 = display
character that follows, 0x09 set color to character that
follows...) proved too slugish.
So, I replaced the thermostat cable with CAT5e and now
I can control the Nest's display in real time (animations,
etc. instead of just a static, numeric display). It's
still a kludge as I don't have direct control over the
Nest's hardware. But, foolish to try to redesign a
product that is already so nicely packaged!
[IMO, the Nest is the ideal UI for a thermostat. But,
*as* a thermostat, I found it sorely lacking!]
Reply by David Lesher●December 4, 20212021-12-04
Thank you for all your responses.
a) This is not a high-production product; rather it's a 1 or 2
off custom device for use with an existing system.
b) That includes a working 1_Wire(tm) system. It uses multiple
Embedded Data System OW-Servers that have 3 channels of 1_Wire
devices, and supports multiple high-level TCP/IP protocols;
no bit banging needed.
c) It works well with multiple devices on long (multiple 100's
of ft) twisted pair cable runs. We've not seen any error issues
so far.
d) The system is based around a custom NXP-based controller. It
talks to the EDS's via TCP/IP. It talks to other industrial gear
via RS-485.
We pondered driving the display via RS-485, but doubt that
offers major advantages. There's no available RS-232 on the NXP,
even if it would run over the cable run available.
Does the above inspire solutions not yet offered?
--
A host is a host from coast to coast...............wb8foz@panix.com
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
Reply by Rick C●November 30, 20212021-11-30
On Tuesday, November 30, 2021 at 6:10:12 AM UTC-4, Don Y wrote:
> On 11/29/2021 6:55 PM, David Lesher wrote:
> > I have a request for a remoted LCD display. Having chased available
> > products to no avail, it's time to honor Bob Pease and roll out the
> > solder.
> >
> > In this specific case, the least parts count approach seems to
> > be 1_Wire as we have that in use already.
> Your conclusion doesn't necessarily follow (just because you have it
> "in use" doesn't mean its the "least parts"). Is cost an issue?
> Availability of alternate sources? Data integrity? Power consumption?
> Flexibility ("future safe-ty")?
> > A {vintage} Dallas/Maxim app note has a reference design:
> >
> > APPLICATION NOTE 3286
> > 1-Wire 8-bit LCD Reference Design
> > Jul 20, 2004
> > <http://tom-itx.no-ip.biz:81/~webpage/pdf/1wire/1Wire%20LCD%20App.pdf>
> Why not skip the display controller, too, and just have a single
> device (MCU) handle the comms *and* drive the display (glass)?
> (don't think of it as "code" but a "different VHDL dialect" :>)
>
> This allows you to augment the capabilities on the display end
> in ways that the above solution simply can't address (without
> adding more components)
>
> What if an "update" isn't received in N seconds? Do you just
> freeze the display with the last value displayed? What if
> N tends towards infinity -- do you ever alert the (remote)
> viewer (user) that he's looking at stale data?
>
> What if updates are received but the data makes no sense?
> Do you try to display it? Or, do you discard it? How is
> this different (from the user's perspective) than an
> "update not received" condition? Can he take different
> remedial actions in each case?
>
> What if you want to add attributes to the display (e.g.,
> blink, inverse video, color, etc.)? Are you going
> to rely on a sufficiently fast update rate from the far
> end to make those happen in "real" time? (e.g., paint
> value, pause, paint blank, pause, paint value, pause...)
>
> What if you want to change the display, itself (to one that
> is functionally identical but uses a different "controller")?
> As that will require changes to the "driving" end of the link,
> will the user know that the device *he* owns can only "talk" to
> a "model X" remote display? (i.e., one can virtualize the
> display interface if you have "smarts" on the remote end)
>
> What if signal quality degrades and you need to renegotiate the
> timing of your protocol? Or, new noise sources become present?
> E.g., With smarts, you can (later) opt to frequency encode the
> data stream without having to change any hardware (no need to
> restrict yourself to just two frequencies!).
While throwing an MCU at the problem has some advantages, spreading a code base over two processors adds complication and makes debug and maintenance more difficult. Your suggested advantages would not seem to be of much value.
--
Rick C.
+ Get 1,000 miles of free Supercharging
+ Tesla referral code - https://ts.la/richard11209
Reply by Jan Panteltje●November 30, 20212021-11-30
On a sunny day (Tue, 30 Nov 2021 01:55:37 -0000 (UTC)) it happened David
Lesher <wb8foz@panix.com> wrote in <so40ap$44a$1@reader1.panix.com>:
>
>I have a request for a remoted LCD display. Having chased available
>products to no avail, it's time to honor Bob Pease and roll out the
>solder.
>
>In this specific case, the least parts count approach seems to
>be 1_Wire as we have that in use already.
>
>A {vintage} Dallas/Maxim app note has a reference design:
>
>APPLICATION NOTE 3286
>1-Wire 8-bit LCD Reference Design
>Jul 20, 2004
><http://tom-itx.no-ip.biz:81/~webpage/pdf/1wire/1Wire%20LCD%20App.pdf>
>
>This application note describes how a DS2408 1-Wire 8-Channel
>Addressable Switch can be used to display characters on an
>LCD. The code is written using the 1-Wire API for Java. A
>diagram shows how to hook the DS2408 to any LCD using a
>Hitachi-44780-based LCD controller chip.
>
>I welcome brick-bats and suggestions.
> I have a request for a remoted LCD display. Having chased available
> products to no avail, it's time to honor Bob Pease and roll out the
> solder.
>
> In this specific case, the least parts count approach seems to
> be 1_Wire as we have that in use already.
>
> A {vintage} Dallas/Maxim app note has a reference design:
>
> APPLICATION NOTE 3286
> 1-Wire 8-bit LCD Reference Design
> Jul 20, 2004
> <http://tom-itx.no-ip.biz:81/~webpage/pdf/1wire/1Wire%20LCD%20App.pdf>
>
> This application note describes how a DS2408 1-Wire 8-Channel
> Addressable Switch can be used to display characters on an
> LCD. The code is written using the 1-Wire API for Java. A
> diagram shows how to hook the DS2408 to any LCD using a
> Hitachi-44780-based LCD controller chip.
>
> I welcome brick-bats and suggestions.
>
Buy an LCD module that has an integrated RS232 interface? That = 1
wire.... EBAY.
--
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Reply by Don Y●November 30, 20212021-11-30
On 11/29/2021 6:55 PM, David Lesher wrote:
> I have a request for a remoted LCD display. Having chased available
> products to no avail, it's time to honor Bob Pease and roll out the
> solder.
>
> In this specific case, the least parts count approach seems to
> be 1_Wire as we have that in use already.
Your conclusion doesn't necessarily follow (just because you have it
"in use" doesn't mean its the "least parts"). Is cost an issue?
Availability of alternate sources? Data integrity? Power consumption?
Flexibility ("future safe-ty")?
Why not skip the display controller, too, and just have a single
device (MCU) handle the comms *and* drive the display (glass)?
(don't think of it as "code" but a "different VHDL dialect" :>)
This allows you to augment the capabilities on the display end
in ways that the above solution simply can't address (without
adding more components)
What if an "update" isn't received in N seconds? Do you just
freeze the display with the last value displayed? What if
N tends towards infinity -- do you ever alert the (remote)
viewer (user) that he's looking at stale data?
What if updates are received but the data makes no sense?
Do you try to display it? Or, do you discard it? How is
this different (from the user's perspective) than an
"update not received" condition? Can he take different
remedial actions in each case?
What if you want to add attributes to the display (e.g.,
blink, inverse video, color, etc.)? Are you going
to rely on a sufficiently fast update rate from the far
end to make those happen in "real" time? (e.g., paint
value, pause, paint blank, pause, paint value, pause...)
What if you want to change the display, itself (to one that
is functionally identical but uses a different "controller")?
As that will require changes to the "driving" end of the link,
will the user know that the device *he* owns can only "talk" to
a "model X" remote display? (i.e., one can virtualize the
display interface if you have "smarts" on the remote end)
What if signal quality degrades and you need to renegotiate the
timing of your protocol? Or, new noise sources become present?
E.g., With smarts, you can (later) opt to frequency encode the
data stream without having to change any hardware (no need to
restrict yourself to just two frequencies!).
Etc.
Reply by David Lesher●November 30, 20212021-11-30
Thanks for the suggestions.
We don't care that it's slow; if we update every 60 seconds or
so, that's sufficient.
We have a slew of DS18B20's probes in use now.
With CAT5 cable, no noise issues at all.
The DS2408 is supported by the Ethernet server.
--
A host is a host from coast to coast...............wb8foz@panix.com
& no one will talk to a host that's close..........................
Unless the host (that isn't close).........................pob 1433
is busy, hung or dead....................................20915-1433
Reply by bitrex●November 29, 20212021-11-29
On 11/29/2021 9:58 PM, DJ Delorie wrote:
>
> David Lesher <wb8foz@panix.com> writes:
>> I welcome brick-bats and suggestions.
>
> I'll add two bits of experience:
>
> 1. the 1wire protocol is slow. Check the timings and see if you'll be
> able to update the display fast enough.
>
> 2. "Remote" and "1wire" don't play well. Mine is an extreme case (10
> meters of 18 gauge furnace wire) but only one in 4 or so transactions
> actually succeed. Check capacitance and noise on that line. You
> might need to tweak the pull up resistor if you don't have active
> pullups on the driver.
>
A 1 wire interface of some type over a 4-20 current loop is a possibility.