If you made it to this page, welcome. This page contains my response to NPA2026-005 published to CARAC by Transport Canada. This page is a work-in-progress and will continue to be updated until the comment submission deadline on Sept 9, 2026. This page was last updated September 14, 2026.
Thank you for the opportunity to comment on NPA 2026-06. This document contains feedback written by Tom Hastie on the subject NPA. I feel that this is an important regulatory package and it has the potential to set the long-term direction for both commercial and recreational RPAS operations in Canada. The opinions expressed in this document are those of Tom Hastie and do not necessarily reflect the opinions of any other organization. As a (nearly) lifelong member of the model aircraft community, the regulatory analysis here comes from the point of view of a model aircraft pilot. As will be discussed below, CAR Part IX was not written with the model aircraft community in mind, and the CBO component of this NPA, if implemented correctly, has the possibility of providing much needed relief to a hobby that has been severely impacted by the CAR Part IX regulations. If there are any questions or clarifications on the comments provided here, I would be happy to discuss. I can be contacted by email at tom@tomsbasement.ca.
I am an aerospace engineer who got his start as a kid learning to fly R/C Model Aircraft with my father. The hobby sparked a life-long interest in aviation. Along the way I have worked on certified navigation systems and avionics, I have participated in the standards development organizations that developed the Remote ID protocols and developed international and domestic airworthiness standards and regulations for RPAS. I contributed to the initial releases of ArduPilot back when it ran on an ATmega328. I also hold an active Canadian Glider Pilot License and Private Pilot License, enjoy flying sailplanes, instructing new glider pilots and flying the glider tow-plane. I still participate in the hobby that started it all and actively build and iterate on new model aircraft designs. At this stage I am passing on a love of aviation to the next generation as I teach my own children how to fly. I am concerned that the Remote ID regulations as proposed here would further stifle a hobby that has already been decimated by the CAR Part IX RPAS regulations.
This section summarizes my most important comments about each component of the proposal. For further discussion and details see below where section-by-section comments on the NPA text are presented.
Please don't mandate Remote ID for VLOS operations.
This NPA presents Remote ID as a key enabler of future complex, automated Beyond Visual Line of Sight (BVLOS) operations. While I agree that an RPAS Traffic Management (RTM) system is required for these future automatic BVLOS operations, the current de facto standard for Broadcast Remote ID (ASTM F3411 using Bluetooth and Wi-Fi) will NOT support this end state. It currently has range and compatibility problems that will not support future operations. Airspace management is a key service required for safety. As such, RTM needs to be implemented using standardized communication protocols over licensed and segregated spectrum. Requiring that the existing Visual Line of Sight (VLOS) operations equip with Bluetooth/Wi-Fi Broadcast Remote ID will not support a robust, extensible, RTM system and place a huge technological burden on current legal VLOS operations.
If the justification for VLOS Remote ID is security, mandating Broadcast Remote ID for VLOS operation will have a minimal impact on security. Conversations around RPAS security are often divided into the three groups of "careless", "clueless", and "criminal". While there may be a case to be made that Remote ID can assist in locating "careless" and "clueless" operators, it will most certainly not assist with issues created by the "criminal" operators. On the contrary, reliance on Remote ID for security purposes only creates a new threat vector for attackers. A criminal actor can use Remote ID transmissions to spoof many drones in any particular area. These spoofed signals can either be their own attack (i.e. creating delays at an airport), or they can be used to create a diversion (in the case of threats to secure facilities). Above all, any operators who truly do not want to be seen will operate RPAS that are not transmitting Remote ID, or they will broadcast Remote ID that identifies them as someone else. Requiring VLOS operators to equip with Broadcast Remote ID will not address security concerns related to RPAS.
If the justification for VLOS RID is public acceptance, Remote ID does not help drone operators with public acceptance. Rather than improving public acceptance by encouraging dialog between the general public and drone operators, remote ID gives observers a way to report drone operators directly to the government. In my own experience public acceptance comes from two-way conversations with curious observers. Generally, these interactions are simple and friendly. Beyond the fact that Remote-ID does not really work towards public acceptance, there are privacy issues regarding the transmitted data. Even if there is no way for a member of the public to associate a remote ID identification with me personally, I still have concerns over my drone Remote ID being reported to law enforcement (either erroneously or intentionally).
For VLOS operations there is no proof that an operator, performing VLOS per the rules, will have any issue avoiding collisions with other aircraft. The only time there is a risk of collision is when the operator has already ignored their 901.11 responsibilities and flown too far away to maintain VLOS. Remote ID is not required to avoid a collision with another aircraft when operating VLOS.
A Remote ID mandate will not be enforceable. As noted in the NPA, some compliant Remote ID modules only have a 200ft range. In addition to short range, compatibility issues exist that mean that not all handheld devices can receive all Remote ID transmissions. Apple, for instance, restricts third party developers from accessing the raw WiFi stack – thus preventing reception of WiFi based Remote ID signals. Furthermore, Remote ID module manufacturers are already producing Broadcast Modules for pilots concerned about privacy that have minimal performance. Broadcast Remote ID, as it exists today, is not a solid foundation for a robust and future-proof RPAS Traffic Management System.
Remote ID also opens a new attack vector for nefarious actors. If a location needs to be protected against drones (i.e. airport, penitentiary, other secure installation), and a Remote ID scanner is installed as the primary means of detecting RPAS, a bad actor can simply use Remote ID either as a diversion or as the attack itself. For example:
Penitentiary: A criminal element could use a Remote ID transmitter from one location to distract security forces while a drone without Remote ID is used to perform the criminal mission from another direction.
Airport: If one wanted to disrupt traffic at an airport that was using Remote ID to detect drones in nearby airspace, one could simply plant a remote ID transmitter somewhere near the airport. From a nearby roof, the remote ID transmitter could send signals showing that there are multiple drones at multiple critical locations around the airport. The airport will need other means of detection to determine which drones are real and which drones are decoys.
The concept of Remote ID was a direction by the US Department of Homeland Security in 2017 when the UAS Identification and Tracking Aviation Rulemaking Committee was concerned about "rogue" drones in the US National Airspace. In the nearly 10 years since those recommendations were made, the RPAS community has evolved beyond the need for RPAS to be detectable by consumer handheld devices. Adoption of Remote ID in the US airspace did not go smoothly, with many many recreational RPAS pilots citing concerns about privacy, compatibility, lack of availability of Remote ID equipment, and the general lack of effectiveness of using Bluetooth and Wi-Fi protocols for aircraft traffic management. Canada should not building a future RPAS Traffic Management System on a 9 year old recommendation from the United States that is based on outdated technology and whose adoption in other jurisdictions has been problematic to say the least.
I encourage Transport Canada to investigate the multitude of technologies that have been developed over the past 10 years to both detect and counter small RPA. A safety and security framework that relies on these technologies will be much more robust and future proof than relying on Bluetooth and Wi-Fi Broadcast Remote ID. It would also allow a future RTM system to be designed from the ground up using licensed aviation spectrum and sufficient transmitted power levels to form a solid basis for complex RPAS operations.
It is an excellent idea to rely on safety procedures and best practices developed by CBOs as an "alternate means" to CAR Part IX for conducting safe operations.
My primary comment on the CBO framework, is that in order to ensure that the CBO regulations do not suffer the same fate as the MAAC exemption, it is critical that the regulations be structured such that they punish the individual member rather than the Organization in most cases of a non-compliance incident. Except for a very few key cases, an individual who violates CBO rules should simply be excluded from any CBO regulatory-carve out and be subject to the regulations that already exist under CAR Part IX.
A key problem with the proposal as described in the NPA is the assumption that all model aircraft operations will be Remote ID exempt because they are performed under the modified CBO rules. I have concerns that while the fixed model club sites will fit within the CBO framework, the concept of MAAC "Personal Flying Sites" and "Off-site Flyers Program" will not. I, personally, conduct most of my model aircraft activity away from club sites, using empty sports fields, rural lakes and other locations that are suitable. These operations have been performed safely for decades without the technological burden of Broadcast Remote ID. As discussed elsewhere in this document, applying remote ID to these operations exposes me to privacy risks, adds weight and technological complexity to my otherwise simple model, and does not contribute to traffic management, safety or security in any meaningful way.
I agree that 5.1 and CYR are not the correct tool for restricting airspace to small and medium RPAS.
Displaying these areas to pilots needs to be an optional feature of RPAS. Not all RPAS will be able to display a map with up to date geozones. Further, RPAS pilots who are actually in compliance with CAR 901.11 VLOS rules should be monitoring their aircraft location visually rather than consulting a map during flight. GeoAwareness zones should be available in the DSST or similar web sites and pilots should be responsible for these online tools to be aware of applicable airspace restrictions (as part of their CAR 901.27 responsibilities).
The details below include reproductions of specific sections of NPA 2026-06 with comments and discussion. For clarity, I have highlighted the specific passages of the NPA that relate to the associated comment.
While I agree that an RTM system would be required for a future where Amazon, Zipline, Walmart, or other commercial companies use delivery drones in urban and suburban areas to routinely deliver items to residential addresses, Broadcast Remote ID as presented in this NPA does not support this future. As will be discussed later, it does not have the range and suffers from compatibility issues that will make it impossible to integrate into a safety-critical airspace management system.
This future can be attained without putting an excessive burden on existing Part IX VLOS operators who:
a) are responsible for their own separation from both traditional aircraft, and other RPAS,
b) are required to avoid flight in areas where a hazard might be created (i.e. near warehouses with extensive BVLOS drone activity), and
c) will never be of a quantity or density that pose any risk to routine BVLOS operations.
When a drone operator is following Part IX VLOS regulations it is incredibly easy to identify them. The direct line of sight between the RPA and the pilot makes it easy to locate and speak with the pilot. For these RPAS operators there is no need for Remote ID to assist in identifying the Part IX RPAS Pilot.
On the other hand, a nefarious pilot who is doing something that is worthy of an incident investigation, will generally not want to be identified, and therefore will not equip with Remote ID, or will disable the remote ID transmission on their RPA. Even with a Remote ID mandate, alternate means of pilot detection (C2 signal triangulation, following the RPA, visual searches) will continue to be necessary to track down problem pilots.
Remote ID will place a burden on the law abiding RPAS pilots while adding very little investigative benefit.
I am not aware of evidence that "new operations in more complex scenarios" cannot integrate with the existing VLOS drone operations. This is especially true in Canada where there are vast unpopulated areas where, even if dense complex BVLOS operations are being performed, there will be so few VLOS RPAS operations that they will have little or no effect on the "more complex" scenarios. In more urban areas, the existing Part IX regulations that limit flight near and over people, and in controlled airspace already limit VLOS operations to a point where they will never be able to impeded any of the "more complex scenarios" that might be imagined by commercial drone operators.
Currently it is the responsibility of VLOS RPAS pilots to avoid creating a hazard to other aircraft (which includes traditional aircraft as well as other drones).
If the density of automated BVLOS drones is such that it is impossible for a VLOS operation to be performed safely, the BVLOS operation will be immediately and plainly obvious to the VLOS operator. A drone delivery hub might be a warehouse where RPA are continuously arriving and departing. VLOS in the operators in the area will immediately see the RPA traffic in the vicinity and realize that their own operation would create a hazard to the existing traffic.
The expectation of this NPA seems to be that, once a VLOS RPA is transmitting Broadcast Remote ID, the VLOS pilot is somehow relieved their duty to avoid areas that might include hazardous traffic. Given that Remote ID has been positioned as a "complex operation enabler", a VLOS pilot could be excused for thinking that a commercial delivery drone will avoid his RPA because he is broadcasting Remote ID. However, given the range and compatibility issues that will be discussed later, it is unlikely that a commercial delivery drone participating in an RTM system will have a reliable means to detect a Broadcast Remote ID module.
If the sky is darkened by so many BLVOS RPA operations that it is impossible for a VLOS operator to complete their mission I suspect that it will be public acceptance, rather than airspace segregation or other safety concerns that will be the limiting factor for expanded complex drone operations.
Requiring VLOS operations to equip with Broadcast Remote ID modules is unlikely to be a "key enabler" for more complex scenarios such as automated BVLOS in urban areas.
I agree that new approaches for traffic management will be needed if automated BVLOS operations (package delivery and similar) is the end goal. However, small RPA VLOS operations that are manually controlled by pilots who are on-site with the RPA will never be so numerous that anything more than VLOS for traffic management will be required.
While there may eventually be locations where the density of RPAS operations requires that everyone participates in an RTM system, this will not be the case in the vast majority of Canadian airspace for the foreseeable future. Most low-level airspace in Canada will not have the levels of traffic that require an advanced traffic management system.
The Remote ID regulatory framework should focus on locations that need an RTM solution and apply traffic management to those specific regions rather than placing a blanket Remote ID requirement on all operators. As has been discussed, blanket application of remote ID only places financial and technical burden on the existing operators with no safety, security, or traffic management benefit.
The reception by VLOS RPAS Pilots of a Remote ID mandate might be improved if there was a tangible benefit to those pilots from equipping with remote ID. Beyond regulatory compliance, there is no operational benefit noted in the NPA to a VLOS Pilot for equipping with a Remote ID Module or purchasing a compliant RPAS. One possible benefit that I encourage Transport Canada to investigate is the possibility of using Remote ID as an alternate method for accessing controlled airspace. The current method for operating in controlled airspace (i.e. the NAV Drone website/app) is difficult, slow, not very flexible, and results in an automatic approval for most operations. If the requirement for the NAV Drone request was eliminated for RPAS operators equipped with Remote ID, this would serve as a strong motivation to encourage equipage and compliance. Replacement of the NAV Drone request with Remote ID compliance would be justified if, as discussed in the NPA, Remote ID served as the basis for a Canadian RPAS Traffic Management System.
The requirement that Remote ID transmissions can be received and decoded by mobile devices dates back to the FAA UAS ID and Tracking Aviation Rulemaking Committee (ARC) in 2017. This decision, in my opinion, was a huge mistake and eliminates any possibility that Remote ID form a solid foundation for a RPAS Traffic Management System. At the time, law enforcement and homeland defense agencies were deeply concerned about "rogue" drones, and the FAA refused to allow advanced operations (i.e. operations near and over people). They imagined a future where people could use their smartphone to identify a drone they saw in the sky (similar to what can be done with websites like FlightRadar24 and ADSBexchange.com). This led to requirements that effectively limited Broadcast Remote ID to using either Wi-Fi or Bluetooth protocols on the unregulated 2.4GHz spectrum, a decision that has led to the severe limitations of broadcast Remote ID that are acknowledged in this section of the NPA. As I mentioned, this requirement prevents Broadcast Remote ID from having any useful role in a long term, robust RTM. Mandating broadcast Remote ID based on the ASTM F3411 standard places a large technological burden on RPAS pilots without providing a path towards integration within a future-proof RTM system.
In the almost 10 years since the ARC made its recommendations, RPAS technology has evolved, and public acceptance of RPAS operations has increased. Unlike the FAA, Canada also implemented Advanced RPAS operations in 2019 without a requirement for Remote ID. Basing a future RTM on an decision made by a 2017 Airspace Rulemaking Committee ignores the advancement and development in the RPAS community that has occurred over the last 10 years. I encourage Transport Canada to investigate the new technologies for RPAS detection and mitigation that do not require every RPAS to equip with an additional transmitter. These technologies allow interested parties to detect, track, and in some cases counter drones when necessary. They will also continue to improve and adapt as RPAS technology evolves. The Broadcast Remote ID standard, as contained in ASTM F3411 is already out of date, and will continue to suffer from range, compatibility, and security problems.
If the goal truly is to allow members of the public to identify RPAS using their smart devices, then an architecture similar to FlightRadar24, or ADSBexchange.com would be much more sensible. The network RTM system should be built from the ground up to support RPAS Traffic Management (likely using licensed spectrum, higher power levels, and robust communication protocols). Data from the network RTM system (sanitized for privacy) could then be fed to publicly accessible websites, where concerned citizens could get information about a drone operator.
It was stated earlier that the intent of Remote ID is to support the management of BVLOS and more Complex RPAS operations. Presumably a major element of this support will be flight path management, which is fundamental to collision avoidance, airspace integration, and safe operation. This section of the NPA acknowledges that Broadcast Remote ID (as proposed here) does not have the performance to allow RPAS to detect other RPAS. In addition to the privacy and security issues mentioned elsewhere, this proposal would place a large technical and financial burden on VLOS operators who will not see (and do not need) the benefit of a fully networked RTM solution.
The NPA admits that Broadcast Remote ID cannot directly support the main stated goal of Remote ID, which is to support the safe integration of RPAS operations into the Canadian National Airspace.
My main comment here is that there should be a way for members operating under the umbrella of a CBO to have access to flexible flying locations. Not only would this cover my personal operations (small model aircraft operated from private rural fields, or other suitable areas), but other types of CBO that often do not operate from fixed sites (i.e. FPV clubs flying - with permission - at various abandoned sites). CBO operations do not always happen at fixed locations.
There are absolutely some positive elements of the US recreational aircraft model that would alleviate some of the burden on the model aircraft community flying at fixed flying sites.
Transport Canda should endeavour to address the lessons learnt by the FAA through during the development of their recreational model and FRIA site process. A Canadian CBO framework would be very helpful to the model aircraft community that has had a great deal of difficulty adjusting to operations within the Part IX regulations. When Part IX was originally drafted, the model aircraft community assumed that they would not be required to operate under thew new rules because they were told that the MAAC exemption would be put into place. This meant that the public consultation periods were not used to the extent that they should have been. I believe that partly because of this lack of comment in 2018, many Part IX rules were drafted such that they make very little sense for model aircraft operations. These specific regulations are discussed later in this comment document.
Please ensure that the free web-based tools are continued and Geo Awareness does not become something that drone manufactures are expected (or mandated) to include in their products. Many RPAS cannot geo-locate or include things like maps that are live-updated with the latest awareness zones. Awareness of geo zones should be left to the operator as one of their Site Survey CAR 901.27 responsibilities.
As explained elsewhere in these comments, please do not mandate Remote ID for Basic or Advanced Operations.
This is placing a technological and financial burden on RPAS pilots who are performing simple operations, and who have demonstrated over almost a decade of operation under CAR Part IX that they can safely and responsibly operate without the need to publicly broadcast their identification and position over Bluetooth or Wi-Fi.
Remote ID, or more realistically a bespoke RPAS Traffic Management System, does have a role in the growth and safe operation of highly automated BVLOS operations. As acknowledged elsewhere in this proposal, these complex operations will not be directly supported by the mandate for Broadcast Remote ID on Basic and Advanced VLOS operations. The move to require Broadcast Remote ID was ill advised when it was recommended by the US FAA ARC in 2017, and both the RPAS community as well as the counter-RPAS technology has moved beyond the need for remote ID. The Canadian RTM system should not be based on a 10-year-old requirement from the US Department of Homeland Security.
While I agree that this Remote ID solution might be easily supported by a software update to high end consumer drones (i.e. DJI and similar), it is much more difficult to add a broadcast module to a home-built RC plane, and doing so doesn't make sense for supporting any of the issues that Remote ID is purported to solve.
RC model aircraft, and many hobbyist built FPV and other drones do not include GPS and therefore do not have an easy way to get the location requirements for the remote ID standard. They often do not have two-way telemetry to allow the RPA to determine the location of the transmitter. Finally, adding an additional transmitter to an often small/cramped RPA can create electro-magnetic interference (EMI) issues that negatively impact the RPAS C2 link, can reduce C2 link range greatly, and impact the safe operation of the RPAS.
Meanwhile, broadcast modules don't have a safe or easy way of alerting the pilot during flight that they have ceased to function.
For Remote ID to function as described in this paper, a framework based on "Performance Based Requirements" will not work. If ASTM F3411 is seen as a means, but not the only means of meeting the Remote ID requirement, then there is no guarantee that Remote ID transmissions can be received and decoded by third parties.
CAR standard 922 is intentionally written as a "Performance Based" standard. As mentioned in the NPA this means that it specifically says "what" an RPAS designer needs to do, but not the "how". As written today, CAR Standard 922 is technology agnostic and only states the performance goal (i.e. Design a safe drone). The Canadian Drone industry has long appreciated this type of safety standard as it allows for innovation and rapid product development. If CAR Standard 922 were written as a prescriptive standard, it would be impossible for Transport Canada to update CAR Standard 922 at a rate that would accommodate innovation in the RPAS industry.
An example of this at work is CAR Standard 922.04, Operations in Controlled Airspace. CAR Standard 922.04 states that the RPAS must indicate to the pilot the aircraft location to within 10m horizontally and 16m vertically. While most RPAS manufacturers use GPS to accomplish this task, manufacturers are free to use other means to meet the localization standard. I, personally, have declared to Transport Canada that I meet Standard CAR 922.04 by operating VLOS (I can see my aircraft and therefore I know where it is to the required accuracy). This declaration has been audited by Transport Canada and found to meet the spirit of the standard.
If the "what" of a performance based Remote ID standard is to "transmit data related to the aircraft and flight", then manufacturers would not only be limited to using ASTM Standard F3411 and the Bluetooth or Wi-Fi protocols that it specifies. Having a performance-based Remote ID standard as described here would leave the door open for manufacturers to develop their own means and methods of transmitting the required data. For example, one could imagine meeting this performance-based standard by:
Implementing Tom's Basement Morse Code based Remote-ID, Or,
Placing a giant screen next to the operator with the required data displayed on it, Or,
Attaching a banner or a loudspeaker to the RPA to broadcast the required information using visual or auditory means.
Clearly, none of these "performance-based" solutions would assist in the stated goals of supporting RPAS traffic integration, safety and security.
For Remote ID to function as described in this proposal, a performance-based method would not work. Transport Canada will need to be prescriptive in how Remote ID requirements are met if the intent is that remote ID broadcasts can be decoded by third party aps on mobile devices.
I have several comments and questions about the proposed list of transmitted data.
What about homemade broadcast modules that do not have a serial number? Are hobbyists who program their own Bluetooth transmitters to support the Remote ID protocol (and then make a declaration to Transport Canada) allowed to assign their own serial numbers to their remote ID modules? Will collisions between serial numbers be a problem for the RTM system?
When I registered my home-built model aircraft, I assigned it serial number "001". Will I be required to go back into the DMP to change this number to the serial number of a broadcast Remote ID module? How will TC monitor that this has been done? Will I be allowed to use a single Broadcast Remote ID module on several different aircraft (as is allowed in the US for recreational operators).
Many control stations do not support GPS or altitude localization. Please ensure that there is a framework to allow for these.
What about RPA that do not include GPS or altitude sensors? Most model aircraft fall into this category, and requiring GPS and barometric pressure sensors be added will significantly increase the cost and complexity of adding Remote ID modules to these aircraft.
If there is a problem with the GNSS constellation (local jamming, or a problem with the satellite vehicles, urban canyons, mixed indoor/outdoor operations), does this mean that my RPAS (noting that all RPAS require GPS to operate) is grounded?
Not all RPAS operators purchase new RPA on a schedule, and many hobbyists do not purchase ready-to-fly RPA. A significant part of the model aircraft hobby is in building and reusing parts to experiment with new designs and build new aircraft. These hobbyists would be required to purchase add-on modules to equip their fleet. These modules typically cost at least $100 which can become a significant expense considering the cost of other parts of the aircraft. It can also become a significant cost when you consider that some members of the model aircraft community can have dozens of aircraft.
I personally have model aircraft that were built in 2005, over 20 years ago, and are still in active use. I also have a significant amount of RPAS equipment (such as motors, servos, receivers, and speed controllers) that get recycled and reused in new RPAS builds. The assumption that all RPAS pilots replace their fleets once per year is not realistic. This Remote ID mandate would create large financial burden on the average RPAS hobbyist.
The assumptions made in this section make sense for commercial operations that use RPAS as a tool. These operations are motivated to keep their RPAS up to date as newer systems will often have improved cameras, better endurance, enhanced features, and improved automation. However, there is a huge difference between RPAS operators who operate RPA for the purposes of imagery (photography, remote-sensing, commercial applications) and RPAS operators who operate RPA recreational for the enjoyment of aviation.
Recreational operations, unlike commercial RPAS operations, are generally not motivated to replace their fleets on a fixed schedule. As mentioned, I personally have model aircraft that I built in 2005 that I still fly regularly, and even my newest aircraft are technologically very similar to the aircraft I learned to fly as a child. Recreational RPAS do not have a set "life-cycle" as is assumed here.
Especially as model aircraft get smaller, they become less tolerant of added weight. Small model aircraft designs are generally highly optimized structurally and designed to fly best at a very specific wing loading. If I choose to make my smallest RPA compliant with this proposal, the addition of even a 10g Remote ID module will significantly affect the flying characteristics of the aircraft.
The Transport Canada approach to oversight of Safety Assurance Declarations is risk-based, and TC does not automatically review every Safety Assurance Declaration it receives. When it does perform oversight of these declarations, it has been limited to a review of a declarant’s test plans, reports, and other substantiations. Oversight has not extended to independent verification of fielded system performance.
The intent stated in this NPA is that aviation inspectors and other law enforcement personnel could issue AMPs to RPAS operators found to be non-compliant with the Remote ID rule. If a Remote ID broadcast module is sold to the public, and it turns out that the module is not compliant for a technical reason (for instance the enforcement partner's mobile device is incompatible with the remote ID signal transmitted by the RPA), can an AMP be administered? The RPAS operator has fulfilled all of their regulatory responsibilities by equipping with a module listed on the TC list of declared equipment and followed manufacturer instructions related to the module. The manufacturer met the performance based Remote ID standard by transmitting the required data (the “what”) but is not using the protocol (the “how”) that was expected by the enforcement officer’s device. In this case it was the police officer at fault as they did not have a Remote ID receiver that was compatible with the particular equipment being used. How will TC ensure inspectors and law enforcement personnel have devices that can detect all declared Remote ID modules?
I have concerns over how the Remote ID information is linked to personal pilot accounts in the Drone Management Portal (DMP).
I seems that the assumption is that most drone manufacturers would use the serial number of the RPA as the unique RPA identifier for RID purposes. This means that when the RPAS is registered in the DMP, the Remote ID unique identifier would be the RPAS serial number, and this serial number would be used to link Remote ID reports to a personal account in the DMP.
It is less clear how this would work with Broadcast Remote ID modules that are added on to existing RPAS that don't natively support Remote ID. For recreational pilots, the FAA Remote ID framework allows pilots to use the same Remote ID module across several RPA. If the intent is to follow the FAA framework, RPAS pilots would need to register their Broadcast Remote ID modules with the DMP (almost as if they were a stand-alone RPAS). Presumably the RPAS pilot would then be free to move this module around to any aircraft in their fleet that doesn't support Remote ID. If this is the intent, clarification is needed as to whether each aircraft within the fleet also needs to be registered within the DMP. Is the expectation that a RPAS pilot who has already paid $10 to register their aircraft needs to pay another $10 to register their Broadcast Remote ID module? On the flip side, if an RPAS pilot has already registered their Broadcast Remote ID module, are they required to pay an additional $10 for every individual RPA that they attach the module to? It would seem that the Broadcast module is performing the role of connecting the RPAS with the registered owner in the DMP, therefore it seems that registering every aircraft in ones fleet has no added benefit (other than a noticeable financial burden on recreational operators who often have large fleets of model aircraft).
As an RPAS operator, will I be protected if someone (intentionally or unintentionally) programs their remote ID module with the information that is linked to my account and then uses that drone for a criminal operation? It is very easy to build Remote ID transmitters and program them with any unique identifier. Under this scenario, my decision to comply with the Remote ID regulations exposes me to the possibility of investigation if a drone ID tied to my account is detected doing an operation that violates CAR Part IX. Even if this is a highly unlikely situation, it would make many RPAS operators hesitate about submitting their Remote ID information to the Drone Management Portal.
As has been discussed, the assumption that RPAS have life cycles is very commercial-drone-centric, and does not reflect the reality of recreational RPAS operations.
As a member of the model aircraft community, I don't expect to ever purchase an RPAS that is Remote ID compliant "out-of-the-box". Therefore, none of the cost mitigating measures described here apply to me.
The information transmitted by Remote ID is only available to RPAS pilots that fly while also monitoring Remote ID signals. As a VLOS pilot, my biggest concern is maintaining visual contact with my RPA during flight (in accordance with my CAR 901.11 responsibilities) and therefore I generally am not monitoring Remote ID transmissions during flight. This is not a legitimate benefit to an RPAS operator.
For a law abiding RPAS pilot operating VLOS, public acceptance does not come from people being able to use their phone to identify me on a map. Responsible VLOS RPAS operations are done such that the RPAS pilot is always obvious to those people who can see the RPA. Public acceptance for RPAS operations come from the operator being available to answer questions and demonstrate my RPAS capabilities, NOT from publicly broadcasting my personal data.
I disagree with the statement that because data is not personally identifiable it doesn't have the ability affect my privacy, or harm me in other ways. If someone wants to target me personally, they only have to receive and record the data transmitted by my Remote ID module, and report that information as operating in a negligent or hazardous way. As has been discussed above, someone could program that data onto their own drone (or Remote ID spoofing module) and then use that Remote ID information in reportable incidents.
Furthermore, once someone links the transmitted remote ID identifier to me (by watching me fly at a park for instance) they can use this information to personally identify me moving forward. I can easily imagine anti-RPAS websites making lists of RPAS pilots and their remote ID information public. There are already websites intent on shutting down certain model aircraft sites and attempting to publicly shame participants in the hobby. One could easily imagine the authors of these websites using remote ID signals as an additional means of harassing the model aircraft community.
Issues such as these will tend to discourage people who are concerned with data privacy from registering their Remote ID information on the Drone Management Portal. Aside from regulatory compliance, there is very little benefit Remote ID equipage for recreational RPAS operators. For Remote ID to be widely implemented, there needs to be additional incentive to equipage (a good example of a tangible benefit for operators would be streamlined access to controlled airspace as mentioned later in this document.)
As someone who builds their own RPAS, I have specific standards of practice to ensure that my radio link is reliable and operates to the maximum range possible. My primary means of controlling EMI on my aircraft is to limit the number of transmitters on the aircraft to only those required for safety of flight, and to ensure that if RPA to GCS telemetry is required, that the downlink occurs on a different frequency band from the uplink data.
By requiring the addition of a third-party Broadcast Remote ID transmitter you are adding an unnecessary downlink to an RPA that is often highly space constrained (the antennas can't be physically separated from each other), as well as power and weight constrained. For the simplest types of model aircraft, I do not have reliable way of determining if the Remote ID broadcast module is negatively affecting my primary C2 link. For aircraft operating closer to the 250g weight limit, the addition of 10g is more than enough to adversely impact the flight characteristics. Furthermore, in order to comply with VLOS requirements, small RPA must by definition be operated so close to the operator that there is no benefit to transmitting remote ID data from the RPA itself. Addition of a remote ID module would have the same safety and security impact if I was allowed to keep the Bluetooth module in my pocket rather than putting it in a potentially risky situation on board my RPA. Anyone close enough to my RPA to receive the broadcast remote ID information transmitted from my aircraft would also be close enough to the operator to receive the remote ID information transmitted from the operator’s location.
For the small (near the micro RPA size) and short range (a few hundred feet) RPAS, I would ask that the operator be allowed to Broadcast Remote ID information from the pilot location rather than installing a Broadcast Remote ID transmitter in the aircraft itself. Doing so would have the exact same safety and security benefit (anyone seeing the RPA would easily be able to locate the operator) while avoiding the performance penalty of added weight and complexity to the RPA and avoiding the risk of losing an expensive Remote ID module (small RPA are often the victim of trees).
Since CAR Part IX came into force the model aircraft community has found time and time again that any added regulation impedes the growth of the recreational RPAS industry. There is no indication that remote ID will be any different. With CAR Part IX there was a large group of recreational flyers who left the hobby because of the (rightly or wrongly perceived) complicated regulations that needed to be followed. With the loss of the MAAC exception there was another loss of participants to the hobby and many club fields closed because although they had operated for decades safety they could not comply with all the new CAR Part IX regulations.
While commercial drone operators will find ways to comply with the Remote ID regulations out of necessity, there will be many recreational drone pilots who find that Remote ID is the "last straw" and decide that the added technological and financial burdens combined with the loss of privacy and the threat of enforcement and fines makes the hobby no longer enjoyable. With the loss of recreational operators, there will be a decline in companies making model aircraft kits. Mandating Remote ID on Basic VLOS operations will be another blow to the RPAS hobby. There are only very rare cases where added regulations increase participation in a recreational activity, and Remote ID is unlikely to be one of these cases.
This section is omitting the cost of oversight for Remote ID declarations. As discussed above, if non-compliant Remote ID modules are accepted onto the declaration list there it is likely that AMPs will be issued to RPAS pilots who are completely compliant regarding their responsibilities under the regulations. As discussed above added regulations will certainly impede the growth of the RPAS industry, especially at the recreational level.
ISED will also have added costs as Broadcast ID modules will need to be tested for compliance at an ISED-recognized testing facility and then submitted for Certification Body Review.
It is not quite clear what is meant in this paragraph by "increased pilot awareness" that will benefit the government of Canada. It should be noted that in a vast majority of Basic and Advanced VLOS operations, there will be no one receiving the Broadcast Remote ID signal. If the intent is that more people will be aware of the operation, that will not be the case. If the intent is that other pilots will be more aware of other RPAS operating in their vicinity, while this may be the case for some advanced RPAS that are equipped with a map-display and "remote-ID-in", the vast majority of RPAS operators (especially recreational VLOS operators) will be too busy safely operating their RPAS to monitor yet another display. In addition, it has also been acknowledged in the NPA that Broadcast Remote ID signals are very short range. RPAS pilots will only be aware of other RPA via Broadcast Remote ID when those RPA are closer than a few hundred metres from the Remote ID receiver. By this time, a VLOS operator will have already seen the intruding RPA and maneuvered as required.
As discussed above, Remote ID will only assist in identifying the "Careless" and the "Clueless" operators while doing nothing to identify most "Criminal" operations.
As a responsible RPAS pilot I would like anyone that has questions or issues regarding how I am operating my RPAS to come up to me and ask me in person, at the time that I am performing the operation. I have educated countless individuals on model aircraft while operating at local parks and empty sports fields. I have always found people to be curious and interested. Generally, in these cases I'm able to answer their questions, and if there are any specific concerns I can address them on the spot and improve social acceptance of drones directly at the grass-roots level.
As someone who abides by the Part IX regulations, I am always easily identifiable as the pilot of the RPA in question. There is never any doubt that "the person holding a controller and staring at that aircraft" is the one performing the operation. From my perspective, giving people a way to report me directly to government agencies is exactly the opposite of "promoting social acceptance" of drones, and is a huge step backward for the growth of the hobby.
I have compiled a list of the regulations from which I expect a CBO would request exclusion. Refer to my list of problematic regulations later in this document which includes an explanation of why each regulation is problematic for the model aircraft community.
As described in the NPA, it is implied that the CBO would be responsible for registering member RPA with Transport Canada.
From a MAAC perspective, keeping an up to date list of members is no problem, and this is already done today. However, it would be impossible for MAAC to keep an up to date list of member aircraft. The nature of model aircraft is a hobby is that a member’s fleet is in a continuous state of flux. Crashes, repairs, new builds, purchases, and sales, means that managing an up to date list of every aircraft in every member's fleet would be impossible. Current MAAC rules require that MAAC members mark their aircraft with their unique member number. This allows a particular airframe to be linked with the member who has care and control over that aircraft. MAAC members are not required to inform the organization each time they build and intend to fly a new aircraft, and any attempt to keep a list like this would, in my opinion, be impossible to keep up to date.
It is not clear what is meant by programming. If this is referring to a common training curriculum and operational procedures then this is acceptable.
However, I think there should be careful consideration about the need for the CBO to declare fixed sites to TC. It would be preferable for the CBO to simply have a list of fixed sites available for TC review upon request.
Is it TCs intent that the list of fixed sites be added to the DSST for public guidance? Will it be shared with commercial operators to warn them to expect extensive RPA operations without Remote ID? Doing this would benefit the CBO and likely would motivate the CBO to provide the list of fixed sites to TC.
TC needs to carefully consider how cancellation of CBO status is implemented, or the result will be no better than the MAAC Exemption that was previously in place. If the regulations are written such that non-compliance automatically results in revocation of CBO status, then we are no better off than the Exemption we had before (the first rule that is broken results in the CBO status being revoked).
There needs to be some discretion on the part of TC written into the regulation so that a judgment call can be made about whether a particular situation can be resolved without revoking the CBO status. Responsibility needs to be correctly divided between the CBO and operating members of the CBO. In most cases of non-compliance, it should be the member who is penalized (and likely penalized based on CAR Part IX violations) rather than the CBO status being revoked.
I would ask for clarification here regarding whether TC is approving safety procedures or simply accepting them. As the subject matter expert on safe model aircraft operation, I would be concerned if the MAAC safety code was at the whim of the Transport Canada inspector who is assigned to the file. If MAAC "renews" it's CBO status because of an editorial change to the safety code, or because of a change in leadership, there is a risk that if a more cautious inspector is assigned to the file, they might reject the application based on something in the safety code that has an established track record.
This duty to consult requirement needs to be written carefully such that if the party to be consulted does not respond, the CBO is protected and can still establish the fixed site. For example, MAAC found it very difficult to consult with NAV Canada following the establishment of the MAAC exemption and was unable to establish the required airspace agreement (which in part, led to the loss of the exemption). MAAC, unfortunately, does have fields with neighbors who are less than enthusiastic about the model aircraft activity, and may refuse consultation in order to unilaterally stop the establishment of a fixed site.
The duty to consult should be something that can be satisfied by a MAAC consultation process that seeks input, but that doesn't completely fall apart if the consulted parties are non-responsive.
Currently all MAAC members have a unique member number that is issued to them when they first join the organization. This number is theirs for life, and the MAAC safety code requires that all members put this number somewhere on their model. There is no unique number generated per airframe because, as discussed above, MAAC member fleets can be very fluid with significant annual turnover through crash-damage, repairs, trades, sales and new acquisitions. The MAAC number written in or on the model serves to tie the model to the MAAC member who has care and control over that aircraft.
In addition to this, MAAC member fleets are not like commercial drone fleets in that MAAC members will only ever operate one aircraft at a time (in contrast to a commercial drone operator which might often send different operators with different airframes to different jobs). Because each model is unique and often has a lot of time and effort put into it by the owner, lending aircraft to other pilots to operate is done very rarely.
Linking a particular airframe to a particular pilot should be all that is required to support the safety and security requirements of Transport Canada. If an airframe is found in an area that it should not be (i.e. crashed at an airport, or inside a secure/restricted area), the MAAC member number will link directly to the owner/operator of that aircraft, and there is no added value to having a unique number associated with the airframe.
Theoretically, MAAC could issue a block of "tail numbers" to each member. So that member # 1234 might number their airframes as "MAAC-1234-1", "MAAC-1234-2", "MAAC-1234-3" and so on, however, as discussed, there is very little added value in knowing that an incident aircraft is the "-1" or the "-2" airframe owned by member "MAAC-1234". As mentioned above, simply adding "MAAC-1234" to the airframe uniquely identifies the individual operator who has care and control of that airframe.
Given the fluid nature of MAAC member fleets, allowing airframes to be assigned the member number would also avoid a great deal of confusion when, for instance, an aircraft is repaired, or an engine or radio equipment is added. I have often repaired a crash by building or purchasing a new wing. Would an airframe with a new wing require a new "tail-number" to be issued by MAAC? What about an engine replacement? What if all parts except for the RC receiver is replaced? Would I have to inform MAAC if I sell an airframe to a friend? Would I have to inform MAAC if I don't fly an aircraft for a few seasons? Requiring a unique number for each airframe raises questions, adds a great deal of complexity, and adds an enormous paperwork burden for MAAC and MAAC members for absolutely no safety or security benefit.
There is also a key problem with the current registration requirements related to the model aircraft community that has been hinted at above. RPAS owners are allowed to replace any part of their RPAS and still use the same registration number. Effectively, a Part IX pilot is within their rights to register for a single RPAS number, and use the registration number on all of their aircraft. This strategy makes even more sense when one considers that members of the model aircraft community only ever fly one aircraft at a time. One would never see more than one RPAS registered to Tom's Basement airborne at one time. When I land and decide to fly another airframe, through the act of linking my RC transmitter with the next airframe, from a practical perspective, I have simply replaced all parts of the RPA associated with a singular registration number.
Effectively, the way that CAR Part IX is written today, members of the model aircraft community can have fleet registration if they desire. It would be greatly appreciated by the model aircraft community if the CBO framework would support putting only the MAAC member number on each airframe without the need to differentiate between each model aircraft.
It should be noted that prior to CAR Part IX, MAAC fixed sites operated for decades within controlled airspace and even from aerodrome or airport properties without a single recorded instance of a model aircraft interfering with "full-scale" air traffic. It is quite easy to operate an RPAS safely inside controlled airspace, and the model aircraft community has been doing this using the MAAC safety code for much longer than "drones" have existed.
Model aircraft operators at fixed sites are acutely tuned to air traffic in their area. I have personally been at a MAAC club field when an unannounced medical helicopter landed at the flying site. All model aircraft landed when the medical helicopter circled for an inspection pass and gave way for the helicopter to land (it was dealing with a nearby traffic incident). Partly because of the lack of on-board stabilization, but primarily because model aircraft operations are conducted truly VLOS, conflict with full-scale aircraft is never an issue.
In addition to this, not all ground-level controlled airspace is the same. While the Class C airspace near runway thresholds will obviously be very busy, traffic in most of a Class C control zone is kept several hundred feet above ground.
All this is to say that, there is really no need for additional steps when establishing a fixed site inside controlled airspace. The CBO in question should present their process for site approval (in both uncontrolled and controlled airspace) when they apply for CBO status. This process can then be used with minimal additional work by TC (or NAV Canada) when establishing flying sites regardless of their airspace classification.
As mentioned above, the fixed site information transmitted to TC should only include info shared on the DSST or with NAV Canada. Other policies and procedures should be kept and updated with MAAC as necessary and be available upon request. In the case of MAAC, MAAC has spent a lot of time and money developing safety regulations and operational frameworks. While some of these can be shared with Transport Canada, some of it may be considered MAAC proprietary and shared only with MAAC members. While safety is obviously something that should be shared and encouraged with all, there are certain elements of MAAC procedures, and practices that may be reserved for MAAC members only.
Given the past history of the MAAC exemption, a CBO framework needs to be carefully constructed to separate the responsibilities of the CBO from the responsibilities of the individual pilots who operate under the CBO umbrella.
For a robust and resilient CBO framework to exist, revocation of the CBO status must be reserved for fundamental organizational breaches of the CBO contract, and not for infractions of individual members of the CBO. For instance, a CBO framework needs to ensure that if an individual is in violation of any CBO operational rules, that individual would no longer be operating "under the CBO", and would rather be subject to the full requirements of the CAR Part IX rules. We must acknowledge that even model aircraft operators aren't perfect (gasp!), and sometimes they don't strictly follow every rule. CBOs must not be subject to dissolution every time one of their member operators violates a CBO (or Part IX) rule.
On the other hand, it would be reasonable to revoke a CBO accreditation if the CBO rules are found to be inadequate (and there is a refusal to update them) or other systemic violations (such as non-responsiveness to TC communication or requests).
When considering the fee related to being a CBO is introduced, Transport Canada should consider the existing organizations that already govern other types of recreational aviation in Canada. The Soaring Association of Canada (SAC) and the Hang Gliding and Paragliding Association of Canada (HPAC) are both the governing bodies for their sports in Canada. Both provide frameworks for licensing, instructional syllabi, and safety management systems to promote safe recreational aviation in Canada. Neither SAC nor HPAC pay a fee to Transport Canada to act in this capacity. From the description in this NPA, the only difference between the CBO model described here and the existing role of SAC and HPAC in the Canadian aviation ecosystem is the fact that under this CBO ecosystem there may be alternate means of compliance to certain Canadian Aviation Regulations.
Given that other community-based organizations supporting safe integration of recreational aviation into the Canadian Airspace do not pay fees, Transport Canada needs to ensure that any fee structure assessed upon a RPAS CBO is fair and equitable.
If a "per flying field" fee structure is considered, it should be noted that MAAC model airplane fields can be much more fluid than traditional aerodromes and airports are. While some lucky clubs maintain a single flying site for years or even decades, many clubs are forced to move occasionally due to land access, suburban sprawl, and other reasons. Please consider the financial burden on a Community Based Organization if a fee needs to be paid each time a new flying field is activated or deactivated. If assessed on a "per site" basis, fees for CBOs will quickly add up and become an impossible burden for most CBO.
Finally, consider that the goal of a Community Based Organization is to increase the safety of related operations, as well as to reduce the burden on TC of surveilling and monitoring a large subset of the RPAS operational population. Any fee schedule assessed on CBOs should take into account the reduced regulatory burden on TC that comes from the delegation of certain responsibilities to the CBO. In general, the goal of Transport Canada should be to streamline the path to aviation safety rather than putting barriers in that path (such as fees to establish safety-oriented CBOs).
The NPA includes the idea that the CBO framework would allow for certain CBOs to be exempted from certain regulations, with a focus placed on remote ID mandates and aircraft registration mandates. However, there are several other regulations in CAR Part IX that do not make sense in the context of recreational model aircraft operations. As has been discussed above, during the initial development of CAR Part IX it was assumed that the recreational model aircraft community would be covered by the MAAC exemption. This assumption meant that most MAAC members did not consider if or how CAR Part IX would affect their operation, and therefore did not study these regulations in depth, or comment on them when Part IX was being developed. With the loss of the MAAC exemption the model aircraft community was suddenly forced to figure out how to comply with many CAR Part IX regulations that make very little sense or do not provide any additional safety benefit when applied to model aircraft operations.
The list of CAR part IX regulations below are the ones that I believe a CBO like MAAC should be able to apply to be exempt from. The CBO application process would obviously include a demonstration of how the regulatory intent and an equivalent level of safety is met for each regulation to be exempted. The key comment here is that the CBO framework should not be limited to exemptions from Remote ID and aircraft registration. Any prescriptive requirement of CAR Part IX should be eligible for a CBO to define an alternate means of safe operation.
The following is a list of the CAR Part IX requirements that are currently a burden to the model aircraft community and should be considered when developing the CBO framework. For each regulation the problematic regulatory text is listed, the regulatory intent is described, and the reason why the regulation is problematic for the model aircraft community is discussed.
(1) Subject to subsection (2), no person shall operate a remotely piloted aircraft system that includes, as an element of the system, a remotely piloted aircraft having an operating weight of 250 g (0.55 pounds) or more unless the remotely piloted aircraft is registered in accordance with this Division.
The registration of RPA weighing more than 250g is intended to accomplish the following:
Allowing traceability from an RPA to the owner in the event the RPA is found.
Encourage good behaviour by RPAS pilots (as the operator knows the RPA is traceable back to them).
Give TC insight into the types and quantities of drones being used in Canada.
The 1-to-1 registration concept doesn't work well for the model aircraft community mainly because they don’t own and operate aircraft in the same way as traditional Part IX pilots. They crash and reassemble parts over and over into new aircraft. They often have large fleets that can extend into dozens of discrete aircraft. Some models might crash on the first flight and never fly again. Some aircraft are proof of concept experiments that won’t be used more than a few times. Others may last for decades. Store bought model aircraft are generally not serialized by the manufacturer, and the builder/owner generally performs a lot of customization work on their aircraft. There is nothing that really ties a particular Registration number to an airframe. Given all this, the $10 fee to register each and every airframe on the Drone Management Portal becomes an administrative and financial burden on the average model aircraft pilot. MAAC has a requirement that members put their unique member identification number on each of their aircraft. This member number provides the traceability and encouragement of good behaviour that are two key parts of the regulatory intent of CAR 900.13. The remaining item, insight into the types and quantities of drones operated in Canada, could easily be met by a data item shared by the relevant CBO with Transport Canada. I believe it would significantly clean-up the Drone Registration Database if model aircraft were removed and simply addressed by an annual quantity provided by the relevant CBO.
No pilot shall operate a remotely piloted aircraft system unless the registration number referred to in paragraph 900.16(3)(a) is clearly visible on the remotely piloted aircraft.
The intent of this regulation is to ensure that if an RPA airframe is found (especially, if it is found in a restricted location) the RPA can either be returned to the operator (or an investigation into why the RPA was in a restricted area can be started).
The "Scale Aircraft" interest group of the hobby often spend weeks/months/years trying to make their models indistinguishable from a real aircraft except for the size. MAAC allows members to put the required markings (MAAC Member Number, and phone number) inside the aircraft (behind a wing or panel, etc.) to avoid non-scale markings on a scale model. During scale model aircraft contests the judges stand 3m away from the model and points are deducted for all elements of the model that don’t match the full-scale version of the aircraft. Guidance currently from TC is that the Reg number needs to be visible on the outside of the aircraft (ref AIM RPA 3.1). Scale modelers are asking to be allowed to put the registration number on the model somewhere where it can't be seen when the model is assembled, but is obvious if you, say, remove a wing or hatch. If CBO members were allowed to mark their aircraft in this way, it would continue to meet the regulatory intent of CAR 900.14.
(1) A registered owner of a remotely piloted aircraft shall, within seven days after becoming aware that
any of the following events has occurred, notify the Minister that
(a) the aircraft is destroyed;
(b) the aircraft is permanently withdrawn from use;
(c) the aircraft is missing and the search for the aircraft
is terminated;
(d) the aircraft has been missing for 60 days or more;
or
(e) the registered owner has transferred legal custody
and control of the aircraft.
…
This regulation is based on a similar regulation in traditional aviation (CAR 202.57) and seeks to ensure that the database of Registered RPA stays current and applicable.
A traditional crewed aircraft is a much larger asset than most RPAS, and this is especially true of the average model aircraft hobbyist. Recreational model aircraft owners often don’t know if their aircraft is “permanently withdrawn from use”, or if it will be flown again several years down the road. A crash that initially might seem irreparable can often be fixed given time and willingness to do so (in fact this is a key element of enjoyment many get from the hobby). Navigating this requirement to de-register model aircraft when they are not flown can be difficult for many in the model aircraft community.
This can become an especially big issue for owners of large recreational fleets, which might sit unused for several years until they are sold, used for parts or otherwise disposed of. There have also been comments from the model aircraft community that the need to deregister RPAS when a pilot/owner dies can be a burden on family members at a difficult time (for essentially no benefit to the safety and security of Canadian Airspace). For the RPAS registration framework to be improved by the CBO regulatory update, the requirement to deregister aircraft should be addressed. This would be addressed (as noted above) if the CBO framework allowed for CBO members to mark their aircraft with their CBO member number, rather than an aircraft registration number.
(1) No pilot shall operate a remotely piloted aircraft system unless the following procedures are established:
(a) normal operating procedures, including pre-flight, take-off, launch, approach, landing and recovery procedures; and
(b) emergency procedures, including with respect to
(i) a control station failure,
(ii) an equipment failure,
(iii) a failure of the remotely piloted aircraft,
(iv) a loss of the command and control link,
(v) a fly-away,
(vi) flight termination, and
(vii) the detection and avoidance of conflicting air
traffic and other hazards.
(2) If the manufacturer of the remotely piloted aircraft system or the person who has made a declaration referred
to in section 901.194 in respect of that model of system provides instructions with respect to the topics referred to
in paragraphs (1)(a) and (b), the procedures established under subsection (1) shall reflect those instructions.
(3) No pilot shall conduct the take-off or launch of a remotely piloted aircraft unless the procedures referred to in subsection (1) are reviewed before the flight by, and are immediately available to, each crew member.
(4) No pilot shall operate a remotely piloted aircraft system unless the operation is conducted in accordance with the procedures referred to in subsection (1).
The intent of this regulation is to ensure that RPAS pilots have procedures to deal with the most common situations that might arise during RPAS operation. The intent of this regulation is to ensure that for the various contingencies and emergencies, the pilot has a plan to mitigate the risks that could be caused. This regulation also ensures that, if the RPAS manufacturer has specified operating procedures, that these procedures are respected. Finally, this regulation ensures that the procedures can be accessed by the pilot and crew if needed.
Currently, guidance in the AIM states that established procedures shall be in either written or digital format. The term “Established Procedures” is also used elsewhere in the CARs (ref 602.62, 604.50, etc.) where it implies that the term refers to written procedures that are maintained by a Part VI or Part VII operator.
While these types of established procedures are valuable when ensuring safety and coordinating a team of pilots, members of the model aircraft community do not establish formal procedures in this manner. The community-based organization establishes a safety code that provides high level guidance for operations as well as prescriptive rules when necessary to ensure the level of safety of all operations are maintained. Within this framework, each model aircraft pilot establishes their own informal personal procedures based on their experience, risk tolerance, the exact aircraft they are flying, and the conditions of the day.
Model aircraft do not come with detailed operating manuals, and the nature of their operation means that consulting procedures (written or digital) during flight is often impossible. Each member fully understands the parts of the MAAC safety code that are relevant to their operation and generally does not need to have these codes "accessible during flight". The CBO framework should allow the CBO to define what procedures are required to ensure the safety of their operations and mandate whether these procedures need to be "immediately accessible during flight".
(1) Subject to subsection (2), no pilot shall operate a remotely piloted aircraft at an altitude greater than
(a) 400 feet (122 m) AGL; or
(b) 100 feet (30 m) above any building or structure, if the aircraft is being operated at a distance of less than 200 feet (61 m), measured horizontally, from the building or structure.
(2) A pilot may operate a remotely piloted aircraft at an altitude greater than those set out in subsection (1) if the operation is conducted in accordance with a special flight operations certificate — RPAS issued under section 903.03.
A major concern that led to the Part IX regulations was the fact that stabilized drones could be flown higher and farther than the pilot could see the aircraft. This led to a concern of midair collisions with crewed aircraft. The altitude limit of 400ft AGL was set to segregate RPAS operations from traditional aircraft operations to address this risk.
The 400ft AGL ceiling is a huge problem for the model aircraft community because:
- most of their aircraft don't have altimetry systems. Altitude is estimated based on visual judgement and experience.
- Especially for larger models (such as turbine jets), the standard turnaround maneuver (a half cuban eight) will generally be taller than 400ft AGL and is much safer than a horizontal turning maneuver (it keeps the aircraft over the protected area, closer to the pilot, and further from the ground).
- RC Sailplanes need to climb well above 400ft AGL to make use of thermals.
- The VLOS nature of model aircraft operations means that model aircraft pilots are far more focused on the airspace surrounding their model than most other "drone" pilots (if you lose sight of a model aircraft, the aircraft will crash). Traditional aircraft that might come near their area of operation are instantly heard/observed by the pilot and easily avoided.
The 400ft AGL limitation on recreational model aircraft has effectively stopped the activities of RC Soaring, Contest Aerobatics, Large Scale Turbine operations in Canada. A CBO framework should allow for operations above 400ft, given that an equivalent level of safety can be demonstrated. The decades of safe operations prior to the existence of CAR Part IX demonstrates the model aircraft operations can be performed safely without a 400ft AGL altitude limit.
No pilot shall operate a remotely piloted aircraft system unless, before commencing the operation, they determine that the operational volume is suitable by conducting a site survey that takes into account the following factors:
(a) the type of airspace and any requirements applicable to the flight geography, including any specified in a NOTAM;
(b) the altitudes and routes to be used for approach, take-off, launch, landing or recovery;
(c) the proximity of other aircraft operations;
(d) the proximity of airports, heliports and other aerodromes;
(e) the location and height of obstacles, including wires, masts, buildings, cell phone towers and wind turbines;
(f) the predominant weather and environmental conditions and the weather forecast for the duration of the flight;
(g) in the case of a VLOS operation, an extended VLOS operation or a sheltered operation, the horizontal distance from any person not involved in the operation;
and
(h) in the case of a BVLOS operation, the distance from any populated area or sparsely populated area.
It is important that an RPAS pilot is aware of their surroundings during an operation. This regulation ensures that important aspects of the operational area are considered by the operator when planning a flight.
There is confusion amongst recreational operators regarding what is the expected format of a site survey, how often it must be done, in a club field situation whether or not it needs to be done by every person operating, and if one site survey can apply to operations for an entire day of activity.
For established model aircraft fields, most aspects of the site survey are done when the field is first established (i.e. items b), c), d), e), and g)). Item f), weather is covered by the pilot being present at the location for the flight (they won’t fly if they’re uncomfortable with the weather). For item a) and NOTAMS, there are other mitigations that make it unnecessary to check NOTAMS prior to each flight (i.e. recreational pilots at a club field will notice a crewed aircraft or other limiting factors in their airspace and stop flying). CBOs should be able to define their own procedures related to site surveys to address CAR 901.27 requirements.
(1) No pilot shall conduct the take-off or launch of a remotely piloted aircraft unless the operating manuals
applicable to the remotely piloted aircraft system of which the aircraft is an element are immediately available
to crew members.
(2) No pilot shall conduct the take-off or launch of a remotely piloted aircraft to conduct a BVLOS operation
under Division VI unless the RPAS operator’s RPAS operations manual is immediately available to crew members.
This is a carry-over from traditional aviation where the Pilot Operating Handbook is expected to be on board the aircraft and available to the pilot.
The problems with this regulation are closely related to the problems with CAR 901.23 (Procedures). Most recreational model aircraft are not supplied with manuals, and in general modelers do not write manuals for their aircraft. Actual operation is based on the judgement and experience of the pilot, and there are mitigations in place to eliminate any risks in the event judgment and experience are insufficient. Fundamentally, in the case of MAAC operations, the MAAC safety code ensures the safety of people and aircraft not involved in the operation. Finally, the nature of model aircraft operations makes it impossible to refer to an operating manual during flight. The CBO framework should be designed so that CBO members are not required to have paper or digital operating manuals available during the flight.
No pilot shall operate a remotely piloted aircraft system unless it is operated in accordance with the operating manuals applicable the system and, if applicable, the RPAS operator’s maintenance control manual and RPAS operations manual.
RPAS are varied and are not standardized as most traditional aircraft are. As experts in a particular RPAS, the manufacturer is expected to provide manuals and instructions needed for the safe operation of the RPAS. If instructions or manuals are provided, then operators are expected to follow those instructions and manuals.
Similar to 901.31, this is an issue because most model aircraft are not supplied with detailed operating instructions, and many recreational modelers modify their aircraft.
In the model aircraft and homebuilt RPAS community there should be relief for those who have alternate risk mitigations in place. For example, even though the manual that came with this model plane says "don't fly if the propeller is chipped", or "don't use a different battery", the risk mitigations that exist in the MAAC safety code ensure that the only hazard in doing so is that the plane might crash, and the probability of injury to anyone not involved in the operation is very minimal.
A CBO framework should allow modelers/homebuilders to rewrite operating manuals because they have operational mitigations in place. The regulations of CAR Part IX are not meant to protect the RPAS, they are meant to protect people. Therefore, if a CBO can demonstrate that their procedures are sufficient to protect people not involved in the operation, compliance with specific manufacturer operating limitations should not be required.
No pilot shall operate a remotely piloted aircraft system when icing conditions are observed, are reported to exist or are likely to be encountered along the route of flight unless the aircraft is equipped with de-icing or anti-icing equipment and equipment designed to detect icing.
(2) No pilot shall operate a remotely piloted aircraft system with frost, ice or snow adhering to any of the critical surfaces of the remotely piloted aircraft.
The intent of this regulation is to ensure that RPA are not flown when icing could affect safe operation.
Model aircraft are often flown during the winter months, and alternate mitigations are in place that allow flights in snow and ice to be done safely (i.e. The MAAC safety code ensures that a crash due to icing won't hurt anyone). Given this the CBO framework should allow it to be left to the pilot discretion as to whether the amount of snow or ice accumulated on the aircraft is acceptable.
(1) Unless the operation is conducted under Division VI, no pilot shall operate a remotely piloted aircraft
system using a first-person view device unless a visual observer maintains unaided visual contact with the airspace
beyond the field of view displayed on the device in order to detect conflicting air traffic and other hazards and take action to avoid them.
(2) For the purpose of subsection (1), means a device that generates and transmits a streaming video image to a control station display or monitor, giving the pilot of a remotely piloted aircraft the illusion of flying the aircraft from an onboard pilot’s perspective.
This regulation is written with “FPV Goggles” in mind. When an operator is “under the hood” and operating with goggles on they lose some situational awareness of people and airspace around them. The use of a visual operator is to ensure that the operation can maintain VLOS and airspace awareness while the pilot is using the FPV goggles.
This regulation actually matches the MAAC Safety code which requires a spotter for FPV operations to ensure that there are no people entering the area, and there aren't other aircraft flying through the airspace. Generally, this is easily done at MAAC Club fields where there often other people present to act as VO.
However, many FPV pilots might fly alone in a known area without a VO. The CBO framework should allow the CBO to provide alternate means of safe FPV operations. In many cases these operations might qualify as sheltered operations (i.e. FPV flight near and through abandoned buildings).
(1) No pilot shall operate a remotely piloted aircraft system at any advertised event except in accordance with a special flight operations certificate — RPAS issued under section 903.03.
(2) Subsection (1) does not apply to the operation of a remotely piloted aircraft system for the purpose of an
operation to save human life, a police operation, a firefighting operation or any other operation that is conducted
in the service of a public authority.
(3) For the purposes of subsection (1), means an outdoor event that is advertised to the general public, including a concert, festival, market or sporting event.
This regulation is intended to ensure that RPAS operations around large groups of people are performed safely. The SFOC ensures that RPAS operators flying at advertised events have experience and safety procedures in place to do so safely. Initially, this regulation was intended for advertised events that were not aviation related, such as professional sport events or musical concerts. It is important that operators flying RPAS in close proximity with large groups of the general public have the right equipment, procedures and training to do so safely.
Recreational operators will often have “open house” events where they advertise to the public that the club is open for non-pilots to visit and watch the flying. They also often have events where members of other clubs are invited to fly/compete/demonstrate/etc. At the moment, some model aircraft open house events have been interpreted as "Special Aviation Events", and have had the requirements of CAR Standard 623 applied to them.
Model aircraft "fun-fly" events, contests, and special interest get-togethers are some of the most important events the model aircraft community. They generate public interest to grow the hobby, and they foster flying and building skill development. With the loss of the MAAC exemption, the thriving contest community in Canada was effectively grounded. The current interpretation of these events as "Special Aviation Events" that require the full scrutiny of CAR Standard 623 continues to be a huge and unnecessary burden to these events.
Part of the CBO framework needs to allow CBO to develop their own rules to use when holding these open house events. MAAC already has a robust process for event approval, and specific safety rules and procedures to ensure that these events can be held safely. At the moment, the event application process, is driven by the need to comply with the Transport Canada regulations. The overly complex process for event approval is driving many clubs to cancel long standing annual model aircraft events, or driving these events underground. Many clubs have taken all event announcements off social media to ensure that their weekend fun-fly events cannot be mistaken for an "advertised" event. Driving event organization underground like this is the opposite of what should be happening, and does not benefit aviation safety, or the growth of the model aircraft community.
(1) Every owner of a remotely piloted aircraft system shall keep the following records:
(a) a record containing the names of the pilots and other crew members who are involved in each flight and, in respect of the system, the time of each flight or series of flights; and
(b) a record containing the particulars of any mandatory action and any other maintenance action, modification or repair performed on the system, including
(i) the names of the persons who performed them,
(ii) the dates they were undertaken,
(iii) in the case of a modification, the manufacturer, model and a description of the part or equipment installed to modify the system, and
(iv) if applicable, any instructions provided to complete the work.
(2) Every owner of a remotely piloted aircraft system shall ensure that the records referred to in subsection (1) are made available to the Minister on request and are retained for a period of
(a) in the case of the records referred to in paragraph (1)(a), 12 months after the day on which they are created; and
(b) in the case of the records referred to in paragraph (1)(b), 24 months after the day on which they are created.
(3) Every owner of a remotely piloted aircraft system who transfers ownership of the system to another person shall, at the time of transfer, also deliver to that person all of the records referred to in paragraph (1)(b).
This regulation is derived from traditional aviation and is intended to ensure that there is traceability in the operations and maintenance performed on RPAS.
Maintenance of model aircraft is such a fundamental component of the model aircraft hobby, that if an operator were to fully comply with CAR 901.48, it would result in hundreds of pages of paper to support the simplest of model aircraft. Nearly every flight involves adjusting control settings, replacing worn parts, adjusting weight and balance, and repairing minor damage. For most, this is a normal, routine and enjoyable part of the hobby. We repair and maintain our model aircraft fleet to comply with MAAC safety regulations, but also to protect our investment in each model.
Maintaining a log of maintenance and flights does not provide a clear safety benefit. Most in the model aircraft community don’t share their aircraft (so the pilot/crew will never change). Most in the model aircraft community don’t have any maintenance requirements that are based on the number of flights performed by the aircraft (so they don’t need to know how many flights have been performed). It would also be difficult for any inspector to verify that a log is correct. It’s common for modelers to have many (into the dozens) of aircraft airworthy at a time, and fly dozens of flights on a visit to the club field. The paperwork associated with logging all these flights can grow quickly, and for no apparent increase in safety or security.
For item (b), if one takes the definition of maintenance, modification, or repair at their most basic level, then the average model aircraft operator does far more maintenance/modification/repair than the average operator of a consumer camera drone.
- propellers and other structural parts break on rough landings and are replaced between flights.
- bolts vibrate loose and are tightened.
- engine settings are adjusted.
- control surfaces throws and programable mixes are adjusted.
- structures are repaired following both normal use and crashes.
- adjustments are made for the current flight conditions (CG, propeller or blade pitch).
All of these are examples of things that, depending on the definition, could qualify as maintenance/repair/modification.
Some operators may do more maintenance/modification/repair than actual flying. (when flying RPAS as a hobby, people gravitate to the part of the hobby that interests them most). Some aircraft get no maintenance (you fly them until they crash). Other aircraft might get maintenance and modifications between each flight.
Some of these actions are mandatory (the aircraft won't fly or will probably crash if the action is not taken). Others are optional (the aircraft will still fly, maybe it will be difficult to control, maybe performance will be degraded but still safe). However, regardless of the nature of the task, the model aircraft operational limitations (MAAC Safety code, distance from people, nature of the operation) ensures that it is very unlikely that crashes caused by improper maintenance/repair/modification will hurt people not associated with the operation.
The main concerns of the model aircraft community are:
- If the definition of maintenance/modification/repair are unclear, can a hobbyist be fined if they don't make a record every time they modify, repair, or inspect their aircraft? How would a Transport Canada Inspector be able to prove that maintenance was done but not logged?
- If the safety framework around the model aircraft community allows them to crash (either from improper maintenance, or for other reasons) safely, then what value does logging maintenance and flights provide?
- There are no flight currency, or pilot skill requirements for maintaining an RPAS Pilot Certificate (you don't need to demonstrate that you have performed a certain number of take-offs or landings in the last 6 months for instance). Therefore what does maintaining a log of flights on my aircraft provide? For modelers with large fleets, the paperwork quickly becomes burdensome. How could a TC inspector possibly prove that a flight log for a particular aircraft is incomplete or incorrect?
The CBO framework should allow for CBO to develop record keeping requirements that are appropriate for the risk of the operation.
(1) A pilot that operates a remotely piloted aircraft system shall immediately cease operations if any of the following incidents or accidents occurs until such time as an analysis is undertaken as to the cause of the occurrence and corrective actions have been taken to mitigate the risk of recurrence:
(a) injuries to any person requiring medical attention;
(b) unintended contact between the aircraft and persons;
(c) unanticipated damage incurred to the airframe, control station, payload or command and control links that adversely affects the performance or flight characteristics of the aircraft;
(d) any time the aircraft is not kept within horizontal boundaries or altitude limits;
(e) any collision with or risk of collision with another aircraft;
(f) any time the aircraft becomes uncontrollable, experiences a fly-away or is missing; and
(g) any incident not referred to in paragraphs (a) to (f) for which a police report has been filed or for which a Civil Aviation Daily Occurrence Report has resulted.
(2) The pilot of the remotely piloted aircraft system shall keep, and make available to the Minister on request, a record of any analyses undertaken under subsection (1) for a period of 12 months after the day on which the record is created.
The intent of this regulation is to ensure that if accidents occur, they can be tracked and if needed, patterns can be addressed.
In general, this is acceptable because most of the key subsections of the regulation include words like “unintended” or “unanticipated”. In general, recreational operators always anticipate that their aircraft will crash, and have operational mitigations in place to ensure that the crash doesn’t create a hazard. The unspoken rule amongst most model aircraft pilots is that one doesn't fly an aircraft that they hope to get back. Because crashes are anticipated, crashes of model aircraft would not be subject to CAR 901.49 analysis requirements. However, I'm not certain that this is the intended interpretation of this regulation.
Also, injuries can and do occur when operating model aircraft (propeller lacerations being most common). However, typically there is no formal analysis following an injury; operators naturally try not to repeat situations that previously led to injury. An injury analysis of "oops I better not do that again", is likely not the intent of CAR 901.49.
The CBO framework should allow CBO to propose their own crash investigation and injury tolerance policies and develop their own safety management system to ensure that safety of the general public is maintained.
(1) Subject to subsection (2), no person shall operate a remotely piloted aircraft system under this Division unless the person
(a) is at least 14 years of age; and
(b) holds either
(i) a pilot certificate — small remotely piloted aircraft (VLOS) — basic operations issued under section 901.55; or
(ii) a pilot certificate — small remotely piloted aircraft (VLOS) — advanced operations issued under section 901.64.
(2) Subsection (1) does not apply if the operation of the remotely piloted aircraft system is conducted under the
direct supervision of a person who can operate such a system under this Division, Division V or Division VI.
The age limit in 901.54 comes from traditional aviation. The minimum age to hold a Student Pilot Permit is 14.
The 14-year age requirement is a problem for many kids. Some kids will have a parent involved in the hobby who can supervise, but not all will have access to an adult with a Basic RPAS Certificate.
Kids who start in model aviation often become adults who have careers in aviation and this should be encouraged. If restrict participation on model aviation to kids older than 14, we end up excluding a lot of kids from a rewarding activity. As mentioned above, I started in the hobby of model aircraft when I was 8 years old, and it turned into a lifelong interest and a career in aviation.
The CBO framework should allow for CBO to develop ways of including youth in the activity in a safe and responsible manner.
(1) No holder of a pilot certificate — small remotely piloted aircraft (VLOS) — basic operations, a
pilot certificate — remotely piloted aircraft — advanced operations or a pilot certificate — remotely piloted aircraft
— level 1 complex operations shall operate a remotely piloted aircraft system under this Division unless the
holder has, within the 24 months preceding the flight,
(a) been issued a pilot certificate — small remotely piloted aircraft (VLOS) — basic operations under section 901.55, a pilot certificate — remotely piloted aircraft — advanced operations under section 901.64 or a pilot certificate — remotely piloted aircraft — level 1 complex operations under section 901.90; or
(b) successfully completed
(i) any of the examinations referred to in paragraph 901.55(b), 901.64(b) or 901.90(e),
(ii) any of the flight reviews referred to in paragraph 901.64(c) or 901.90(f), or
(iii) any of the recurrent training activities set out in section 921.04 of Standard 921 — Remotely Piloted Aircraft.
This regulation is based on traditional aviation and is intended to ensure that RPAS pilots stay up to date with operating rules and regulations
The recency requirements, especially the activities listed in 921.04 are designed by Transport Canada with the intended audience of a multi-rotor operator in mind. In general, multi-rotor operations are very different from model aircraft operations, and therefore the recency activities currently don’t do a good job of addressing the knowledge requirements of the model aircraft community.
For MAAC pilots it is more relevant to stay current by reviewing updates to the MAAC safety code rather than completing the Transport Canada pilot recurrent training activities in 921.04.
The CBO should framework should include the ability of a CBO to develop safety seminars that could be endorsed by TCCA as valid means of maintaining currency. This is already done in the gliding community (where annual safety seminars can meet the requirements of CAR 401.05). A CBO like MAAC should be able to develop safety seminars that are applicable to their operations. These could become a part of the regular meetings held at various clubs, and attendance at one of these MAAC seminars would cover the 921.04 requirement.
This Division applies in respect of the following operations of a remotely piloted aircraft system:
(a) the operation of a small remotely piloted aircraft to conduct a VLOS operation, (i) in controlled airspace,
…
…
(iv) within three nautical miles from the centre of an airport, or within one nautical mile from the centre
of a heliport;
(b) the operation of a small remotely piloted aircraft to conduct an extended VLOS operation in uncontrolled
airspace;
(c) the operation of a small remotely piloted aircraft to conduct a sheltered operation;
(d) the operation of a medium remotely piloted aircraft to conduct a VLOS operation, …
This regulation defines the types of operation that require the pilot to hold an Advanced Pilot Certificate.
Most recreational model aircraft operators do not want to operate near or over people. The primary model aircraft operation that is affected by this regulation is the operation in controlled airspace and occasionally operation near airports and heliports.
Some MAAC members who have safely operated in controlled airspace for quite some time have difficulty completing the Advanced Certificate Exam. The main reason for this is that in addition to controlled airspace, the Advanced Certificate Exam was written with operations near/over people in mind as well as operations at airports and heliports. The examination is also written with the assumption that most RPAS being operated are stabilized multirotor aircraft. Most model aircraft operations are un-stabilized and manually flown fixed wing or rotorcraft. This means that very little of the knowledge requirements on the Advanced Certificate exam actually apply to model aircraft, and prior to attempting the exam a model aircraft pilot needs to learn a lot of new information that they have never seen before. Furthermore, the costs associated with an Advanced Pilot Certificate tend to assume that the candidate intends to perform commercial for-profit operations. The exam is $10, the issuance of the Advanced Pilot Certificate is $25, and the flight review generally costs approximately $200. When taken together, the requirement for an Advanced Pilot Certificate can become a barrier for many people looking to operate fixed wing model aircraft at an established club field that happens to be in controlled airspace.
There are many (often elderly, or people younger than 16) model aircraft pilots who have been eliminated from flying at their local model aircraft field because of their inability to pass the Advanced Pilot Certificate. On the other hand, model aircraft pilots do not want to exercise the full privileges of an Advanced Pilot Certificate (flight near and over people, or operation of RPA up to 150kg). The CBO framework should allow CBO to justify that their pilot training curriculum provides an equivalent level of safety to that of an Advanced Pilot Certificate within their scope of operations.
(1) Subject to subsection (2), no person shall operate a remotely piloted aircraft system under this Division unless the person
(a) is at least 16 years of age; and
(b) holds either
(i) a pilot certificate — remotely piloted aircraft — advanced operations issued under section 901.64, or
(ii) a pilot certificate — remotely piloted aircraft — level 1 complex operations issued under section 901.90.
(2) Subsection (1) does not apply if the operation of the remotely piloted aircraft system is conducted under the direct supervision of a person who can operate such a system under this Division or Division VI.
The minimum age of 16 for an Advanced Pilot Certificate is based on the minimum age for a traditional pilot license. It is intended to ensure that those pilots who are performing the envisioned Advanced Operations (which are generally commercial operations) have the maturity and responsibility to do so.
Other than the age concern which has already been discussed above, another major concern from MAAC members is the fee that most flight reviewers charge. Existing Part IX drone schools tend to charge in the neighborhood of $200 to complete an Advanced Certificate Flight Review. While the situation has improved (I personally provide Flight Reviews to MAAC members free of charge), depending on the location, finding a flight review can be a financial and logistical problem for many model aircraft pilots.
As mentioned above, the CBO framework should allow for a CBO to justify that their pilot training curriculum has an equivalent level of safety to an Advanced Pilot Certificate when considering the risks and mitigations of their specific operations.
(1) No holder of a pilot certificate — remotely piloted aircraft — advanced operations or of a pilot certificate
— remotely piloted aircraft — level 1 complex operations shall operate a remotely piloted aircraft system
under this Division unless the holder has, within the 24 months preceding the flight,
(a) been issued a pilot certificate — remotely piloted aircraft — advanced operations under section 901.64 or a pilot certificate — remotely piloted aircraft — level 1 complex operations under section 901.90; or
(b) successfully completed
(i) any of the examinations referred to in paragraph 901.55(b), 901.64(b) or 901.90(e),
(ii) any of the flight reviews referred to in paragraph 901.64(c) or 901.90(f), or
(iii) any of the recurrent training activities set out in section 921.04 of Standard 921 — Remotely Piloted Aircraft.
This regulation is based on traditional aviation and is intended to ensure that RPAS pilots stay up to date with operating rules and regulations
Refer to the analysis for 901.56 above for details. In short, the recurrent training activities of CAR Standard 921 are targeted at drone operations and are not well suited to the needs of a safe and responsible model aircraft pilot. The CBO framework should allow the CBO to develop, maintain, and administer its own tailored recurrent training programs similar to what is done today in traditional aviation.
No pilot shall operate a remotely piloted aircraft system under this Division to conduct any of the following operations unless a declaration to the Minister has been made in accordance with section 901.194 in respect of that model of system and in respect of each of the technical requirements set out in Standard 922 applicable to the operation:
the VLOS operation of a small remotely piloted aircraft in controlled airspace;
…
This regulation is intended to ensure that RPAS used for Advanced Operations have a level of safety, design assurance, and reliability required to accomplish those operations safely. This regulation places technical responsibilities on RPAS manufacturers who intend for their products to be used in higher risk RPAS operations.
Access to controlled airspace has been extremely difficult for the model aircraft community since the loss of the MAAC exemption. The two problematic requirements are the required safety assurance declaration, and the requirement for an Advanced Pilot Certificate. The advanced certificate requirement was discussed above in 901.62.
CAR 901.69 effectively requires that RPAS used in Controlled Airspace meet CAR Standard 922.04. Unlike typical RPAS that comply with 922.04 using technological means (i.e. GPS), MAAC model aircraft have operated safely for decades in controlled airspace by mitigating the risk through operational procedures. Model aircraft are operated VLOS, and always close enough to the pilot that the position of the aircraft can be determined visually. This disconnect has led to at least a few Safety Assurance Declarations (i.e. Tom's Basement) that are effectively using operational mitigations to address what was intended to be a technical requirement on the RPAS. This is not how the safety assurance declarations framework was intended, and having all MAAC members make safety assurance declarations against 922.04 would be difficult to manage with the existing DMP process flows. The declaration system was designed with mass produced RPAS in mind, not one-off amateur-built aircraft. Furthermore, many MAAC member pilots who have demonstrated the ability to safely operate model aircraft in controlled airspace do not have the technical knowledge to responsibly make a safety assurance declaration against CAR Standard 922.04.
The CBO framework should allow CBOs to demonstrate that their operations can be safe using means that do not fit neatly within the Safety Assurance Declaration and CAR Standard 922 frameworks.
(1)No pilot shall operate a remotely piloted aircraft in controlled airspace under this Division unless an authorization has been issued by the provider of air traffic services in the area of operation and, if requested, the following information has been provided to that provider:
(a) …
(2) Despite section 901.25, a pilot may operate a remotely piloted aircraft in controlled airspace under this Division at an altitude above those referred to in that section if an authorization to that effect has been issued by the provider of air traffic services in the area of operation.
(3) No pilot shall operate a remotely piloted aircraft in controlled airspace under this Division unless the authorization
referred to in subsection (1) is easily accessible to the pilot during the operation.
This regulation ensures that RPAS operators who fly in controlled airspace submit adequate information about their operation to NAV Canada.
As written, this requirement assumes that each pilot needs to submit a separate NAV Drone request for every registered aircraft operated at a club field. As is the case for many regulations in Part IX, this works fine for many commercial drone operations, but does not work for model aircraft at a MAAC Club setting. Most of these flights are between 0 and 10 minutes long, and the NAV Drone mobile app, as it works currently, makes operators define their operation “from scratch” for each flight. This can take 3-5 minutes depending on the operator’s recent familiarity with the app. Futhermore, it becomes frustrating to users when these operations tend to be “auto-approved”, and from the standpoint of several operators operating at the same location, there is no apparent benefit to have each individual pilot submit a NAV Drone request.
At the moment it is difficult to get agreement from NAV Canada for simplified access to airspace. In the past, model airplane clubs that were situated on or near controlled airports were able to generate agreements with the local tower and operate safely. Typically the agreement was a phone call to the tower at the start and end of operations with the commitment to monitor a cell phone during operations. The requirements of CAR 901.71, however, make agreements like this impossible.
The CBO framework should allow the CBO to make alternate agreements with NAV Canada to support the operation of RPAS in controlled airspace.
For the purposes of an application for a special flight operations certificate — RPAS, the following
operations are low-complexity operations:
the operation, other than for the purpose of providing a commercial air service, of a remotely piloted aircraft
system that includes a remotely piloted aircraft that is not registered in accordance with Division III;
and
the operation of a system at an advertised event.
…
This regulation requires that an SFOC be attained prior to performing certain higher risk operations. For the purposes of this regulation, the intent of “Advertised Event” was meant to be large public gatherings such as sporting events, concerts, and festivals.
As has been discussed above, the original intent of the advertised event regulation was not meant to apply to RPAS related advertised event. During the initial public outreach for CAR Part IX, TC indicated that advertised events were meant to apply to concerts, festivals, and other exhibitions where the public was in attendance, and an RPAS operator might also be filming the event. TC public outreach initially stated that a group of RPAS enthusiasts, flying together would not be considered an advertised event because all of the participants were there to fly and observe RPAS, and therefore would be considered "part of the operation".
However, over time, the Transport Canada stance on RPAS events has changed, and recently any gathering of model aircraft pilots that was advertised to the general public (i.e. a club "open house") has fallen into the advertised event category, and triggered a large amount of background paperwork as well as SFOC fees. The CBO framework should allow the CBO to define a standard process for advertised events that might not always trigger the need for direct Transport Canada oversight.
As discussed in the CAR 901.41 analysis above, a major issue for the model aircraft community currently is that model aircraft events have been interpreted as "Special Aviation Events" under the CARs. This leads to the full application of CAR standard 623. Applying safety regulations intended for traditional aviation airshows to model aircraft shows and contests does not make sense given their relative risk level to the public and aviation. In addition, it serves to drive many events "underground" which tends to reduce the level of safety at these events.
In conclusion I encourage TC to use the opportunity afforded by this regulatory update to address the issues that the loss of the MAAC exemption has caused for the model aircraft community. I also encourage TC to consider carefully if a Broadcast Remote ID mandate (a policy initially proposed by the American Department of Homeland Security over ten years ago) is really the correct foundation for a RPAS Traffic Management System in Canada. Thank you for the opportunity to comment on this Notice of Proposed Ammendment, and I am happy to discuss any of my comments above further.