Help! My shiny new P2 EDGE doesn't work! ++++SOLVED++++

2»

Comments

  • Rayman wrote: »
    Hmm... I thought all Parallax boards were required to have the PropPlug beanie side up...

    Looks like it has to be beanie side down here...

    Yes its beanie side down, so you can see the red and blue leds. Ie opposite side to what Cluso just posted
  • jmgjmg Posts: 14,539
    VonSzarvas wrote: »
    Well, the arrow points inward to the Edge pad for the pad that receives data inward.
    And the arrow points outward, away from the Edge pad, for the pad that transmits data outward.
    Maybe it's the label on the Plug plug being on the side of the pad that it is. Although those triangles are qualified with the RX or TX markings to make things clear.

    That's exactly the problem - there are no labels, so users are left to guess what the designer might have intended.
    Hopefully, it can be fixed on the next board batch.
  • Cluso99Cluso99 Posts: 16,909
    edited 2020-11-16 - 03:52:35
    Tubular wrote: »
    Rayman wrote: »
    Hmm... I thought all Parallax boards were required to have the PropPlug beanie side up...

    Looks like it has to be beanie side down here...

    Yes its beanie side down, so you can see the red and blue leds. Ie opposite side to what Cluso just posted
    ie opposite side to what Cluso just posted ??? Do you mean without the beanie or overlay? I don't have a real PropPlug so I don't actually know what they look like.

    I just took the image and mirrored it to get it in the correct orientation for the way it needs to be plugged in. This shows the arrows conflict with the arrows on the edge and jonnymac board.

    The edge and jonnymac should have, from left to right (note the arrows have to be reversed to what is currently on the boards as they are wrong)
    TX  RX  /RES VSS
    ^    v    
    
  • Cluso99 wrote: »
    Tubular wrote: »
    Rayman wrote: »
    Hmm... I thought all Parallax boards were required to have the PropPlug beanie side up...

    Looks like it has to be beanie side down here...

    Yes its beanie side down, so you can see the red and blue leds. Ie opposite side to what Cluso just posted
    ie opposite side to what Cluso just posted ??? Do you mean without the beanie or overlay? I don't have a real PropPlug so I don't actually know what they look like.

    I just took the image and mirrored it to get it in the correct orientation for the way it needs to be plugged in. This shows the arrows conflict with the arrows on the edge and jonnymac board.

    The edge and jonnymac should have, from left to right (note the arrows have to be reversed to what is currently on the boards as they are wrong)
    TX  RX  /RES VSS
    ^    v    
    

    The prop plug needs to be plugged in so you can see the LEDs. Which means beanie side down (on those old prop plugs that had a beanie). The newer ones don't.

    As far as I can tell the edge board legend has the correct arrows, but the Jonnymac board has them the wrong way around

    Here's some photos showing correct (tested) orientation for rev A and D prop plugs



    3456 x 4608 - 617K
    3456 x 4608 - 745K
  • Cluso99Cluso99 Posts: 16,909
    edited 2020-11-16 - 05:47:55
    I've was confused. I thought the two boards I put in my pics a few posts back were the edge and the jonny mac boards, whereas in fact they were both jonny mac boards.
    I now realise they are the same jonny mac boards, one with components and one without.

    I agree Lachlan. The arrows are wrong on the jonny mac board, but they are correct on the edge board (apologies Von, I was mistaken).

    It's a shame there is no overlay on the top side of the PropPlug. Makes it an easy way to get it wrong.
  • This seems to be confusion stemming from the location of the markings- they could be either side of the pads, and are positioned where they are because of the space available on each board-- ie. if the markings where moved to the other side on the 64020 board, then the header itself would obscure the labels. With the Edge module there was even less space, so the label positions are on the other side and are clear whilst the optional header is not fitted.

    For both products the arrows are draw consistently with respect to the pad: The arrow points "in" for receive, and points "out" for transmit. The Prop-Plug slightly deviates due to the location of the header, but RX/TX was added there to make things clear.

    Remember, these sockets were designed for Parallax Prop-Plugs. The markings are simply a way to provide clues for the customer about which way to connect the Prop-Plug. Let's be honest here- It's helpful for Parallax if customers use the Parallax adapter- not just in terms of tech support, but also sales support !

    For customers wanting to use non-Parallax adapters then sure, they might want to consult the docs to verify which pin does what.

    All that said- the room for multiple interpretations is noted. I've added a note for a future rev to add text (maybe "RX" and "TX") to the 64020, so that will help customers with other serial adapter brands. And if there is a way to improve the markings for orientation of the Prop-Plug (and Edge module also), that will be looked at too. We already have the later in progress, which will be included in the upcoming product and docs release.
  • Looking at this a little whilst documenting the feedback, it seems the simplest solution that covers all silk-screen positions and perspectives would be to replace the arrows with RX/TX, rather than having both. That then should suit all serial adapter types, ie. Prop-Plug and other brands, and avoid the need for explanation/docs.

    I'm sure that can be done on the next build.

    Sound good ?
  • The confusion comes from the fact, that in communication there is a sender and a receiver. In a duplex communication there a two separat communication lines in one physical cable. So the role of tx and rx as a whole is no longer given on the phy layer, but on a higher protocol level. Introduction of master and slave function leads to unnecessary confusion. The same is true for a client/server connection when suddendly your browser reacts to requests from the server which switches the logical level. Whenever symmetry is broken, difficulties arise.
  • Yeah, I get that.

    With 64020 (for example), you could hold the Prop Plug top-down (as Tubular posted 4 or 5 posts above) or bottom-up (with respect of the header pins), and see the arrows pointing in different ways. That bottom-up view might be logical to many, as the pinouts are simple to compare that way. It's always going to be a matter of interpretation.

    There's also the point that the 64020 sits between the Prop Plug and Edge Module. Does that make 64020 a node, or an extension. If a node, then it should also have the TX/RX reversed with respect to the previous and next hops. If an extension of the socket (which it is in this case), then it need only reflect the P2 Edge Module pinout. Again, initial interpretations and opinions may vary.

    On balance, and given that the inter-connectivity options will only grow, it probably seems cleaner to label the pins with some sort of human readable notation and include a diagram in docs. Trying to make it any clearer will likely fail amongst all possible combinations. If we have a consistent model which matches Prop Plug, but is also generic enough to be understood by 3rd party adapters, then I think that's about as good as we can get. At some point people will need to consult the docs if they are not using the hardware designed for- which is totally fine of course.

    768 x 1365 - 186K
  • I'm a fan of arrows when it comes to this kind of thing.

    Von I'm trying to see it as you say "referenced to pad" - does this mean if you moved the legend under the 4 x 0.1" male pins you'd swap the arrow directions? If so, then this would get my vote. Not that I'm all that worried about it personally.

  • Tubular wrote: »
    "referenced to pad" - does this mean if you moved the legend under the 4 x 0.1" male pins you'd swap the arrow directions?

    Yes, that's what I meant.

  • Dave HeinDave Hein Posts: 6,204
    edited 2020-11-16 - 13:18:57
    As far as aligning the Prop Plug there's really no confusion. I just make sure VSS/GND is aligned correctly. Now if you're designing your own USB-to-Serial adapter or wiring up the Prop yourself, then you need to know which line is transmitting to the Prop, and which one is transmitting to the host. I think my suggestion of using the labels HRX/HTX or PRX/PTX would be clear to a designer. An arrow that is printed on a PCB is a bit confusing. Does the arrow mean going into the PCB or going out?

    When in doubt consult the specs.
  • VonSzarvas wrote: »
    Yeah, I get that.
    ...
    There's also the point that the 64020 sits between the Prop Plug and Edge Module. Does that make 64020 a node, or an extension. If a node, then it should also have the TX/RX reversed with respect to the previous and next hops. If an extension of the socket (which it is in this case), then it need only reflect the P2 Edge Module pinout. Again, initial interpretations and opinions may vary.
    ...

    TX of one side goes to RX on the other side, Output to Input that is just how the dataflow works.
    An extension in between does not change this logic:
    PlugExtens.png

    Arrows need to point in the same direction along the path, otherwise they are very missleading.
    To make it totally clear something like that would be good:
    ClearLabels.png

    Andy
    742 x 371 - 16K
    180 x 248 - 4K
  • Ariba wrote: »
    VonSzarvas wrote: »
    Yeah, I get that.
    ...
    There's also the point that the 64020 sits between the Prop Plug and Edge Module. Does that make 64020 a node, or an extension. If a node, then it should also have the TX/RX reversed with respect to the previous and next hops. If an extension of the socket (which it is in this case), then it need only reflect the P2 Edge Module pinout. Again, initial interpretations and opinions may vary.
    ...

    TX of one side goes to RX on the other side, Output to Input that is just how the dataflow works.
    An extension in between does not change this logic:
    PlugExtens.png

    Arrows need to point in the same direction along the path, otherwise they are very missleading.
    To make it totally clear something like that would be good:
    ClearLabels.png

    Andy

    We think the same. My use of the word "extension" was misinterpreted from that I had intended, but no matter, your diagram shows we are on the same page.

    Ultimately there will be a way to make things clearer without adding clutter. The arrow direction only works if the same path is taken, so adding duplicate arrow sets sure does clarify that, although there are other design elements in the mix too.

    I think Dave Hein commented earlier how many different ways people view this topic- and this thread continues to grow in support of that!

    Thanks for all the views.
  • In the broadcast world we know this trouble

    We use "from" and "to" a location for audio connections.
    So; "from Paris", and "to London"...

    If we only use tx(=to) and rx(=from) you mis something, Paris and London.

    The wire "TX" in Paris is not the wire "TX" in London, and you guarantee have trouble.
    The wire "from London" in London is the wire "from London" in Paris....
    TX and RX are not singel delimiters, if you don't know the source

    => to P2, from P2
  • That RX/TX labeling is always confusing.
    Om my schematics I use label with three leters: pRX = Propeller-RX or processor-RX, then I know if it is data to or from the chip.
  • Ltech wrote: »
    In the broadcast world we know this trouble

    We use "from" and "to" a location for audio connections.
    So; "from Paris", and "to London"...

    If we only use tx(=to) and rx(=from) you mis something, Paris and London.

    The wire "TX" in Paris is not the wire "TX" in London, and you guarantee have trouble.
    The wire "from London" in London is the wire "from London" in Paris....
    TX and RX are not singel delimiters, if you don't know the source

    => to P2, from P2

    Signals are not RX or TX - ports are. A TX port on one side connects to an RX port on the other, but the wire connecting the two ports is neither TX nor RX.
  • jmgjmg Posts: 14,539
    VonSzarvas wrote: »
    Ultimately there will be a way to make things clearer without adding clutter..

    I do not see text plus arrows as being clutter. The purpose of silk overlays is to avoid wasted time and user confusion.
    As Dave Hein says above, you do need to indicate which TX the letters refer to. Prop or Host ?

  • Cluso99Cluso99 Posts: 16,909
    edited 2020-11-17 - 00:58:38
    jmg wrote: »
    VonSzarvas wrote: »
    Ultimately there will be a way to make things clearer without adding clutter..

    I do not see text plus arrows as being clutter. The purpose of silk overlays is to avoid wasted time and user confusion.
    Agreed
    As Dave Hein says above, you do need to indicate which TX the letters refer to. Prop or Host ?
    NO!

    TX or TXD means transmit as in transmit output from the board/connector.
    RX or RXD means receive as in receive input into the board/connector.
    TX connects to RX at the other end, RX connects to TX at the other end.

    There is no Prop or Host involved, and to add it just seeks to compound the problem.

    It's a very clear definition from well before the 1970's, which predates even the mini-computer, UART chips and microprocessor chips. It was part of the RS232 spec which may have even copied from somewhere elsewhere. IRC TXD and RXD was used in the 20mA current loop interface used by ASR terminals which FWIW is not RS232.

    Postedit: my quote tags were the wrong way around hiding my "Agreed" text
  • jmg wrote: »
    I do not see text plus arrows as being clutter.

    Nor do I.

  • VonSzarvas wrote: »
    jmg wrote: »
    I do not see text plus arrows as being clutter.

    Nor do I.
    Agreed.

    Anything that makes it clearer to the user helps. But it needs to not be ambiguous. Unfortunately many people interpret things differently.
    I recall an Apple study in the 80's where they asked a group of people which monitors were color monitors. Most answered color to the green monochrome, amber monochrome, and color (rgb) monitors and black and white only to the black and white monochrome monitor.

    (seems my "agreed' text was being hidden in my previous post. fixed now)
  • I like Andy's suggestion. Seems clear enough.
    180 x 248 - 4K
  • Rayman wrote: »
    I like Andy's suggestion. Seems clear enough.

    + 1

    I worked on minis and super minis for several years after university and was astonished at how often the serial connections were at fault when there were problems. Of course at that time there were a few more signals than TX and RX to deal with. Can not get much simpler now that we are down to a 3 wire connection.
Sign In or Register to comment.