Sorry for the delay, but both the wire bundle and screws are now available for purchase. Motor Accessories – CTR Electronics
Wow! That was fast!!!
I’m not trying to be a jerk about this, but we are trying to make plans for things we have on hand. This depends quite a bit on whether we can get get replacements in the future. We’d probably prefer the ThroughBore if we were starting from scratch, but we already have a few Hex Bore Encoder Housings. Are these the only ones we’ll ever be able to get?
Are you asking if they’ll continue to sell the CANcoder? Its one of their best products, so I’d presume yes. Or if they’ll sell just a hex housing for CANcoders?
We also have a stockpile of hex housings, bought them when VEX had a massive sale. If you’d like to buy some off me shoot me a PM.
The Hex Bore Mag Encoder Housing will not be available for sale on https://ctr-electronics.com any time in the near future.
@daltzsmith Will CTR Electronics be publishing any data on the PDP 2.0 related to the efficiency improvements it has over the PDP 1.0 and PDH? Thanks.
Another day, another cool new product release. Introducing the CTR Electronics CANrange.
Need a precise and adaptable proximity sensor? Look no further than the CANrange. This innovative device offers accurate distance measurements and customizable settings to emulate your preferred sensor behavior.
CANrange measures the distance to objects in front of it and can provide a settable proximity detection to emulate popular no-contact proximity sensors.
Features Include:
- Distance Measurement
- Proximity Sensor
- 100 Hz maximum sampling rate
- Factory Calibrated
- Fully Enclosed sensor
- Integration with Phoenix 6 API & Devices
I see the product page says the recommended environment is indoors - how sensitive to sunlight would you say the sensor is?
EDIT: Also, when will documentation be released? Thanks!
Given that this only has one pair of CAN connectors, how do you recommend teams to connect it to the CAN bus while maintaining correct topology, especially on CAN FD?
Also, is this the same sensor IC as on the other CAN distance sensors in the FRC space (ST VL53L1X)?
can this be used as a remote sensor for position control? I could see some niche but very convenient uses for it as a remote sensor for a kraken
If this is the VL53L1X, what does this number represent, given that the sensor sampling period is 24 ms in the best (shortest-range) case?
100 Hz represents one of the possible sampling rates of the CANrange, that number is accurate.
Does it work to detect polycarbonate? What about reflective surfaces, like the diamond plate sides of the arena in 2022?
Take a close look at the spark max CAN wires… CAN wiring is simpler than you may think.
Like other ToF sensors, transparent and reflective materials will have difficulty being detected. The CANrange works best when used with a non-reflective or transparent surface.
Can you share what the min/max expected frequency range is expected to be? Otherwise this post feels like saying that “a possible speed of a 2005 honda civic is 250mph”. (Technically possible but I really want context for that figure.)
I believe it’s just determined by the status signal’s update frequency in the code, no?
If that’s the case, it’s a slightly misleading number because in the prior CAN distance sensors the limiting factor was the sensor IC sampling rate, which depended on configured range.
Excellent question, and we’ve clarified our product page to be more clear. There are 3 distinct modes the CANrange can be placed in. These modes configure how often the sensor captures data, not the rate at which data is sent over the CAN bus.
- “Long Range”: 5-50Hz measurement rate at up to 3 meters
- “Short Range”: 5-50Hz measurement rate at up to 1 meter
- “Fast Short Range”: Fixed 100Hz measurement rate up to 1 meter
Long and Short range have a user configurable range 5-50Hz as shown above. “Fast Short Range” is it’s own independent mode that locks the sensor into 100Hz.
A higher measurement frequency results in more noisy data, but distance is unaffected. Users should determine how much noise (which is application dependent) impacts their application when configuring the sensor update rate.
Out of curiosity, does setting a lower update frequency just average/filter the higher-frequency sensor for easier data handling (IE, noise smoothing) for the user, or is it literally just polling the sensor less frequently? If it’s the latter, it seems like users would still need to implement their own smoothing code to handle any outlier results (meaning there probably wouldn’t be much benefit to a lower polling rate beyond system resource utilization), but if it’s the former, that could be quite a nice way to save programmers some time.