X-CCR Questions

Let's not get carried away. CAN is a fine standard, but it has at least three wiring standards, one of which is described as "fault-tolerant". Even then, one nice thing about this fault tolerance is that all the devices are connected two 2 wires (and ground), so there's no single point of failure, and if one wire goes bad, let's say shorted to ground, it can still use the other. One bad thing is that, if both wires are shorted to ground, the whole network goes down. This is a situation that an evil single point of failure system with a central hub would have no problem dealing with; isolate, and keep the rest working. So CAN is not perfect. With that in mind, and considering the amount of information available about either DiveCAN (since that's what we're talking about here), or whatever the xccr is doing, to wit: none whatsoever, it's more than a bit premature to call anything "better", never mind "the best".



Totally agree. I'm all for digital communication, I really am, but at the end of the day, it's not about being digital or CAN or whatever the buzzword of the day is, it's about what it does, not how it does it.

Cheers,

Matthieu



I'm with you. CAN or no CAN means nothing about the function and abilities of the whole system. The only thing: I want to know, what it does. If it's CAN, than there is a standard and everybody knows how it works. If it's proprietary (means IQSub) I just want to know how it works.
If it's going bad and IQSub is gone, nobody knows what this maschine is doing-no, I wouldn't buy something like this.
 
Does that mean that the controller will try to maintain the setpoint until the O2 is exhausted, as in firing the solenoid almost continuously above 3 meters when using a 1.3 setpoint if a handset is nonfunctional?

Michael

Micahel, in this case it switches to 1.0 so that it does not fire needlessly.
 
In my opinion, canbus is a much misused word. Our system uses two way digital communication with the ability to plug in multiple handsets, HUD, etc. We are not so concerned about the ability to have multiple controllers with the X-CCR as the electronics/controller are in the head and function perfectly even in the handset controller were to be lost.

misused how? it either is or it isn't. If you are using a can-bus system, then say you are and preferably which standard. If you are not, then say in no uncertain terms "IQ Sub chose to design their own digital control network as opposed to choosing a CANBUS system" instead of throwing out vague answers. This is a pretty black and white question, it either is, or it isn't.
 
misused how? it either is or it isn't. If you are using a can-bus system, then say you are and preferably which standard. If you are not, then say in no uncertain terms "IQ Sub chose to design their own digital control network as opposed to choosing a CANBUS system" instead of throwing out vague answers. This is a pretty black and white question, it either is, or it isn't.

Tbone, perhaps "misused" is not the appropriate phrase. We are not trying to be vague in anyway.

The X-CCR uses a DIGITAL UART connection The main electronics are in the head and a data terminal display is in the handset.

Hope that helps!

Kind regards,
Randy
 
Last edited:
I think there is a need for a bit of clarification here. CANbus is a very specific term. It specifies the wire characteristics, how backup power is provided, how errors are handled, how packets are formed, error recovery management, and many other aspects of the communication system. It is extremely robust and proven in the field. It is used by virtually all systems in cars including brake-by-wire and steer-by-wire. It is used for fire control systems in tanks. The entire communication protocol, not just the physical layer, is implemented in hardware.

If you would like more information we posted some here: http://www.rebreatherworld.com/show...hat-s-the-fuss&p=452349&viewfull=1#post452349

Bruce
 
Not to beat a dead horse but, :deadhorse, it sounds to me like the real question is what protocol is used to connect the secondary to the xccr head. It sounds to me like the secondery is just reading the analog output from the cells. Is this the case?
 
I think there is a need for a bit of clarification here. CANbus is a very specific term. It specifies the wire characteristics, how backup power is provided, how errors are handled, how packets are formed, error recovery management, and many other aspects of the communication system. It is extremely robust and proven in the field. It is used by virtually all systems in cars including brake-by-wire and steer-by-wire. It is used for fire control systems in tanks. The entire communication protocol, not just the physical layer, is implemented in hardware.

If you would like more information we posted some here: http://www.rebreatherworld.com/show...hat-s-the-fuss&p=452349&viewfull=1#post452349

Bruce

Cool.

So which physical layer is DiveCAN using?
- ISO 11898-2: High-speed medium access unit
- ISO 11898-3: Low-speed, fault-tolerant, medium-dependent interface
- something else

Cheers,

Matthieu
 
Cool.

So which physical layer is DiveCAN using?
- ISO 11898-2: High-speed medium access unit
- ISO 11898-3: Low-speed, fault-tolerant, medium-dependent interface
- something else

Cheers,

Matthieu

We use the low speed PHY. The high speed it used mostly for entertainment systems, as far as I know.

Bruce
 
I think there is a need for a bit of clarification here. CANbus is a very specific term. It specifies the wire characteristics, how backup power is provided, how errors are handled, how packets are formed, error recovery management, and many other aspects of the communication system. It is extremely robust and proven in the field. It is used by virtually all systems in cars including brake-by-wire and steer-by-wire. It is used for fire control systems in tanks. The entire communication protocol, not just the physical layer, is implemented in hardware.

If you would like more information we posted some here: http://www.rebreatherworld.com/show...hat-s-the-fuss&p=452349&viewfull=1#post452349

Bruce

Bruce,

I have a unit which runs Canbus and your handset/hud. Your RBW link talks a lot about the upsides of Canbus. In your view what are its biggest downsides?

2nd Question: My assumption is that Canbus is also less proprietary than other systems, how true is this assumption? In other words, how open are the standards of Canbus for a suitably competent business or individual to develop a handset which could plug into Canbus rebreathers and become a primary controller or HUD?

Final question: With technology evolving so quickly where do you see rebreather controller platforms in 5 years and what can we expect from Shearwater?


Sent from my iPhone using Tapatalk
 
None of these are easy questions, but I'll try to answer.

From an electrical or protocol viewpoint, I can't think of any downsides. We spent a lot of time evaluating communication hardware and software and CANbus ticks all the boxes. They are a little more expensive since you need to use a microprocessor that supports the CAN protocol, and then you need transceiver chips. Virtually every microprocessor comes with a built in UART, but low end chips don't support CAN. Still, the additional cost is minimal in the context of a system. The wet-connect 1000 meter connectors are very expensive compared to a Fischer connector, but the connectors add a lot of value to a standardized communication protocol.

I would agree that they are less proprietary. You can buy off-the-shelf software/hardware to monitor CANbus communications. Everything except the contents of the data packet is specified in the protocol. It is almost completely immune to electrical interference, and a 100 meter cable length isn't a problem. The CANbus standard is completely open. You can read about it here: http://www.kvaser.com/software/7330130980914/V1/can2spec.pdf

We have already worked with ISC on their CANbus implementation. They make their own devices but can also plug-in our devices. Due to the wide adoption of CAN in boats, cars, tanks, transport trucks and factory automation, many engineers are familiar with CAN systems. (On our systems, the controller is in the head, so handsets are only user interface devices.) It is certainly possible for a skilled engineer to connect to our bus, but for us to be interested there would have to be a viable value proposition for Shearwater.

That is one of the primary reasons for CANbus and wet connectors. We can evolve components individually without destroying the diver's investment in their rebreathers. Firmware can be updated to support new devices. Oxygen sensor monitoring and solenoid control is a very simple problem. Sensor/actuator designs are well understood. The value will continue to be in providing simpler, more intuitive, safer and easier to use systems.

Bruce
 
With the XCCR having a C02 sensor, do we know what the replacement cycle is for this sensor? as well as the cost?
 
After reading what I could about the X controller I have a question. If the diver sets the controller to operate at a low sp but operates the unit by orifice or manually at a higher sp will the handset display an alarm?


Sent from my iPad using Tapatalk
 
After reading what I could about the X controller I have a question. If the diver sets the controller to operate at a low sp but operates the unit by orifice or manually at a higher sp will the handset display an alarm?


Sent from my iPad using Tapatalk

Hi Fred,

If the diver wants to run the unit manually, there is a manual setting. This way it allows the diver to maintain whichever PO2 he wants without an alarm driving him nuts. In manual mode, it will maintain a minimum set point of .4 just as a parachute.

Hope this answers your question.

Kind regards,
Randy
 
Lots of technical questions, which is great, and expected. I personally witnessed Randy diving the X-CCR in cave country in mid to late January with no issues, on deep tri-mix diving in cave country, to Diepolder 3, Eagle's Nest and Camp Indian Springs. I used the Defender CCR on all those dives, a demo unit. I have been using the Hammerheads since 2008 with nearly 800 combined hours, on both the Classic (Rev C) and Extreme (Rev D). I highly recommend these new CCR's, as a logical step up in electronics, the HH's are built to the same standard as the new versions. Less issues with electronics are a blessing.
 
Back
Top